------- Comment #35 from davek at gcc dot gnu dot org 2010-01-27 17:55 ------- (In reply to comment #34)
> digressing too much in this thread: for sure, if I just take the one-liner > provided by submitter the errors I get are the same, with and without > -std=c++0x, and with 4.4.x I can compile it with no errors, irrerspective of > the command-line switches. Right, you mean the one-liner #include <boost/mpl/size.hpp>, so of course if you compile it either different way the live #ifdefs respond correctly, and in the non -std=c++0x compile, you don't get the template definitions for the wide char types. I don't have boost installed, so I've been relying on the preprocessed source, which of course is good only for C++-0x. (I wasn't clear whether you were implying that the charXX_t definitions should exist in non-c++0x mode, but I think now that they are c++0x only and that because you were using live boost headers your compile succeeds.) > This is what I consider sane behavior modulo the > *possible*, yet to be confirmed, C++ front-end issue with specialization / > redefinition. Testsuite run is showing nothing unexpected either, and I couldn't really imagine what Cygwin could possibly have done to break the presence of a couple of builtin types in the C++ FE anyway. So yes, sorry for taking some time to get to this point, but I now also think that's the only possible issue here, and there is no cygwin specific problem nor char types problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
