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:
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