www.digitalmars.com         C & C++   DMDScript  

c++.beta - DMC-8.49.1 + Boost-1.33-1 internal compiler errors and other todo

reply Arjan <arjan ask.me> writes:
See the following link for details

http://www.arjanknepper.com/drupal/?q=node/4
Jul 03 2006
next sibling parent reply Daniel James <daniel_james fmail.co.uk> writes:
Arjan wrote:
 See the following link for details
 
 http://www.arjanknepper.com/drupal/?q=node/4

Thanks for doing this, I had a go at the 688 error and got: namespace newline { const int posix = 1; } class newline_filter { void foo() { int x = newline::posix; } int newline() { } }; Could you add which tests that the files are from? These files are very big (too big for my normal windows text editor). I've found a good approach is to start with the test file and reduce that to make it as simple as possible, and then remove as many headers as possible, which tends to make the generated code a lot smaller.
Jul 03 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Daniel James wrote:
 Thanks for doing this, I had a go at the 688 error and got:
 
 namespace newline {
 const int posix = 1;
 }
 
 class newline_filter {
     void foo()
     {
         int x = newline::posix;
     }
 
     int newline()
     {
     }
 };

The source code is incorrect, but of course the compiler should give the right message instead of an internal error.
Jul 03 2006
parent reply Daniel James <daniel_james fmail.co.uk> writes:
Walter Bright wrote:
 Daniel James wrote:
 Thanks for doing this, I had a go at the 688 error and got:

 namespace newline {
 const int posix = 1;
 }

 class newline_filter {
     void foo()
     {
         int x = newline::posix;
     }

     int newline()
     {
     }
 };

The source code is incorrect, but of course the compiler should give the right message instead of an internal error.

That's what I thought at first, but it's actually valid. From 3.4.3:
 During the lookup for a name preceding the :: scope resolution
 operator, object, function, and enumerator names are ignored.

Although, Boost generally avoids writing code like this, as several compilers have problems. It comes from a test, not the library implementation.
Jul 04 2006
parent Walter Bright <newshound digitalmars.com> writes:
Daniel James wrote:
 Walter Bright wrote:
 Daniel James wrote:
 Thanks for doing this, I had a go at the 688 error and got:

 namespace newline {
 const int posix = 1;
 }

 class newline_filter {
     void foo()
     {
         int x = newline::posix;
     }

     int newline()
     {
     }
 };

The source code is incorrect, but of course the compiler should give the right message instead of an internal error.

That's what I thought at first, but it's actually valid. From 3.4.3: > During the lookup for a name preceding the :: scope resolution > operator, object, function, and enumerator names are ignored. Although, Boost generally avoids writing code like this, as several compilers have problems. It comes from a test, not the library implementation.

Thanks, I understand now. I think I have it fixed. I don't understand, however, what the rationale might be for this lookup rule. It makes for unnecessary complexity (not just for the compiler, for anyone trying to understand the code).
Jul 04 2006
prev sibling parent Arjan <arjan ask.me> writes:
Daniel James wrote:
 Arjan wrote:
 See the following link for details

 http://www.arjanknepper.com/drupal/?q=node/4

Thanks for doing this, I had a go at the 688 error and got: namespace newline { const int posix = 1; } class newline_filter { void foo() { int x = newline::posix; } int newline() { } }; Could you add which tests that the files are from?

I will add that information to the page. These files are very
 big (too big for my normal windows text editor). I've found a good 
 approach is to start with the test file and reduce that to make it as 
 simple as possible, and then remove as many headers as possible, which 
 tends to make the generated code a lot smaller.

That is a good tip! At first I try to locate the offending statement(s) / code- block in the original code. Sometimes its possible to create a simple sample direct from that piece of code. When the above approach fails, I fall back to the "-e -l" method. The samples on the page are all produced by "-e -l". Arjan
Jul 03 2006
prev sibling parent Daniel James <daniel_james fmail.co.uk> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Arjan wrote:
 See the following link for details
 
 http://www.arjanknepper.com/drupal/?q=node/4

Pavel mentioned the 1848 ICE ice1848.cpp (libs/type_traits/test/is_abstract_test.cpp) elsewhere, and like he said, it does seem to be caused by the size of the tests. The test file contains this: #if !(defined(BOOST_MSVC) && (BOOST_MSVC < 1310)) // MSVC prior to VC7.1 always runs out of swap space trying to // compile these, so leave them out for now (the test fails anyway). Set the preprocessor command to '#if 0' and the ICE goes away (I wasn't able to check if the test passes or fails as there's something wrong with my setup). I managed to reduce the 2147 ICE (libs/lambda/test/switch_construct.cpp) to the attached file. It could probably be reduced further, but I've got other things to be getting on with right now. I'm pretty sure the ICE happens when instantiating the lambda call (ie. the call to func() in foo), and has something to do with the complexity of the call. It doesn't occur if some of the variable names (eg. if n_action is made any shorter) are made a little shorter which perhaps gives a clue to what's going wrong.
Jul 09 2006