The attachments are a pair of compiler output/source code runs. The "good" ones compile OK; the "bad" ones report errors. The difference? One blank line of whitespace. And the reported errors are in a function about ten functions below where the whitespace change is. Use diff to see where - it's in the second function named "equate(". I've seen a lot of bugs in gcc, but I don't think I've ever seen one that depended on whitespace :-) Ivan
Created attachment 8483 [details] compiler output (-v) - bad
Created attachment 8484 [details] compiler output (-v) - good
Created attachment 8485 [details] source code (-save-temps, compressed) - bad
Created attachment 8486 [details] source code (-save-temps, compressed) - good
One thing, this is definitely invalid code: /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long unsigned int> >::<anonymous enum>â is/uses anonymous type /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg) â /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long unsigned int> >::<anonymous enum>â is/uses anonymous type /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg) â /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long unsigned int> >::<anonymous enum>â is/uses anonymous type /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg) â /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long unsigned int> >::<anonymous enum>â is/uses anonymous type /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg) â /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long unsigned int> >::<anonymous enum>â is/uses anonymous type /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg) â /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long unsigned int> >::<anonymous enum>â is/uses anonymous type /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg) â /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long unsigned int> >::<anonymous enum>â is/uses anonymous type /home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg) â Well the reduced testcase might not be though.
The code around the problem: typedef typeof(to(0, models.size())) i_t386; i_t386& a;
Re comment #5: I don't get the messages reported by Andrew, and I really rather doubt that those messages (form a different compiler version than I'm using) are legit. They are flagging stuff inside a stock "boost" library, and I have some confidence that boost stuff is OK. Looks to me that whatever the bug is it causes the compiler to start complaining at a random point in the source - with my 3.4.0 the complaint is in my own code, with Andrew's it's in a boost library, but both complaints are bogus. Just a suspicion.
(In reply to comment #7) > Re comment #5: I don't get the messages reported by Andrew, and I really rather > doubt that those messages (form a different compiler version than I'm using) are > legit. They are flagging stuff inside a stock "boost" library, and I have some > confidence that boost stuff is OK. Looks to me that whatever the bug is it > causes the compiler to start complaining at a random point in the source - with > my 3.4.0 the complaint is in my own code, with Andrew's it's in a boost library, > but both complaints are bogus. The error messages are correct as far as I know. I am using the mainline (as of a couple of days ago). The error in Boost I think are fixed in a newer version of Boost. I will try to reduce this later tonight, it just will take me a while because I have to remove all the invalid code.
Andrew - can you confirm getting the same problem I do if you run it in 3,4,0?
(In reply to comment #9) > Andrew - can you confirm getting the same problem I do if you run it in 3,4,0? yes which is why I pointed out in comment #6 the code around where the problem is.
This is really a non-bug. The following code snippet illustrates this: ============================ #define VAR1(i,j) i##j #define VAR2(i,j) VAR1(i,j) #define VAR(i) VAR2(i,__LINE__) #line 385 int VAR(i) = 0; ============================ The code snippet compiles fine on my i686-pc-linux-gnu machine. If I add an empty line before the last line, I get the following error: bug.cc:386: error: expected unqualified-id before numeric constant A look at the preprocessed versions reveals the mystery. First the "good" example: ============================ # 1 "bug.cc" # 1 "<built-in>" # 1 "<command-line>" # 1 "bug.cc" # 385 "bug.cc" int i385 = 0; ============================ The preprocessor magic constructs a variable consisting of the letter "i" and the line number. That's also the case with the "bad" example. But, "i386" is the name of another (compiler defined) macro which is then substituted by its value "1": ============================ # 1 "bug.cc" # 1 "<built-in>" # 1 "<command-line>" # 1 "bug.cc" # 385 "bug.cc" int 1 = 0; ============================ I don't know how boost generates the variable names in your example, but it looks like it uses a similar mechanism to turn line numbers into variable names. The significant difference between yor "good" and "bad" example is the following line which works fine with line number 388, but not with 386: - typedef typeof(to(0, models.size())) i_t388; i_t388& i388 = to(0, models.size()); for(typename i_t388::iterator i = i388.begin(); i != i388.end(); ++i) { + typedef typeof(to(0, models.size())) i_t386; i_t386& 1 = to(0, models.size()); for(typename i_t386::iterator i = 1 .begin(); i != 1 .end(); ++i) { So closing as funny/interesting, but still invalid.
Funny indeed - that's a scream :-)
You can use -pedantic to get rid of the automatically defining of i386 or use -Ui386.