gcc version 4.5.0 20100126 (rev. 156253) is not able to compile the following "program": #include <boost/mpl/size.hpp> version 20100115 didn't complain. I've checked it on boost 1.37 and 1.39. For those who don't have boost installed, there is a preprocessed file from boost 1.39.
Created attachment 19724 [details] preprocessed boost 1.39 mpl/size.hpp
Created attachment 19725 [details] compiler error output
I'm seeing two problems here: on x86_64-linux I can see only the last error, about specialization / redefinition, can well be a non-bug but can also be a regression, I'm CC-ing Dodji about it; plus, apparently something is specifically going wrong on cygwin at configure time, I see char_16t etc issues. I'm CC-ing two cygwin maintainers about it.
(In reply to comment #3) The new compiler was built with gcc-4.5.0 20100115. Both were configured as follows: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper. exe Target: i686-pc-cygwin Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap --en able-version-specific-runtime-libs --enable-shared --enable-shared-libgcc --with -gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --with-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages =c,c++ Thread model: posix gcc version 4.5.0 20100126 (experimental) (GCC)
Ok. If you could figure out more precisely *when* the first problem started on cygwin, it would be very useful.
I tried building the preprocessed source with my stock 4.3.4 compiler. The first two error messages are about the undefined wide char types, then there's a massive cascade of template errors following on from that. Cygwin provides a uchar.h that defines char16_t and char32_t. I checked that none of the #-directives in the preprocessed source referred to uchar.h, so if boost fails to include it and boost gets an error about these types being undefined, I think that is likely to be a boost bug rather than a cygwin or gcc problem. I therefore don't propose to investigate this any further, unless new evidence comes to light.
Thanks Dave. Thus, essentially, is submitter wrong that the problem is new? (the other issue, which I can reproduce on x86_64-linux, stays)
Also note: something is going on with char16_t / char32_t which I do not understand at all, at the moment: in that tr1_impl code I did not setup the specializations for char16_t / char32_t conditionally to some configure check or header included or actual target, because I was assuming that in C++, in C++0x mode, those are **always** available. Is that not true? And we didn't realize for all this time?!? Note, actually the error means the submitter is passing -std=c++0x on the command line.
(In reply to comment #7) > Thanks Dave. Thus, essentially, is submitter wrong that the problem is new? My code compiled flawlessly on 4.5.0-20100115, otherwise I would have reported the issue earlier... 20100126 has been built in a clean directory, so no interferences with previous builds are possible. Paolo: yes, -std=gnu++0x -- it's the reason I use trunk.
(In reply to comment #8) > Also note: something is going on with char16_t / char32_t which I do not > understand at all, at the moment: in that tr1_impl code I did not setup the > specializations for char16_t / char32_t conditionally to some configure check > or header included or actual target, because I was assuming that in C++, in > C++0x mode, those are **always** available. Is that not true? And we didn't > realize for all this time?!? I don't understand. There's no equivalent in g++ of the builtin stdint types that Joseph added for C, so if you don't include the header that defines them, no definitions should be available, yes? > Note, actually the error means the submitter is passing -std=c++0x on the > command line. That didn't make any difference to the undefined types errors, but it did fix a lot of the knock-on errors I was seeing.
(In reply to comment #9) > (In reply to comment #7) > > Thanks Dave. Thus, essentially, is submitter wrong that the problem is new? > > My code compiled flawlessly on 4.5.0-20100115, > otherwise I would have reported the issue earlier... Can you attach the preprocessed source you get from that build of the compiler, so we can see why it either a) finds definitions of the ucharXX_t types, or b) doesn't attempt to declare templates referring to them?
Then say that explicitly, *always*. Actually, the complete command line is part of the requirements for PRs. But, anyway, that error with char16_t and char32_t doesn't make *any* sense to me. We have plenty of testcases in the C++ testsuite for char16_t and char32_t on all the targets, working fine without including any header. Can you compile something as simple as this: char16_t a; with -std=c++0x (or -std=gnu++0x)? If you can't, then this is something which is much more general than boost MPL; if you can, something inside boost MPL is playing weird tricks with those names.
Dave, please grep the C++ testsuite for char16_t and char32_t: you will find tons of testcases using those types + -std=c++0x on the command line, no special target-dependent treatments, no includes whatsoever.
(In reply to comment #12) > on all the targets, working fine without including any header. Can you compile > something as simple as this: > > char16_t a; > > with -std=c++0x (or -std=gnu++0x)? This is from head r.156219 $ cat test.cpp char16_t a; DKAdmin@ubik /tmp/boost $ g++-4 -std=c++0x -c test.cpp ; echo $? 0 DKAdmin@ubik /tmp/boost $ g++-4 -v Using built-in specs. COLLECT_GCC=g++-4 COLLECT_LTO_WRAPPER=/gnu/gcc/install-lto/opt/gcc-tools/bin/../libexec/gcc/i686-p c-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/gcc/configure --prefix=/opt/gcc-tools -v --with-gmp=/u sr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs -- enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --wi th-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --disable-symver s --enable-libjava --enable-interpreter --program-suffix=-4 --enable-libgomp --d isable-libssp --disable-libada --enable-threads=posix --with-arch=i686 --with-tu ne=generic CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 --with-ec j-jar=/usr/share/java/ecj.jar --disable-win32-registry --disable-libgcj-debug -- enable-lto --enable-languages=c,c++,fortran,java,lto,objc,obj-c++ --enable-graph ite Thread model: posix gcc version 4.5.0 20100121 (experimental) (GCC) DKAdmin@ubik /tmp/boost $
And this is r.155967 $ cat test.cpp char16_t a; DKAdmin@ubik /tmp/boost $ g++-4 -std=c++0x -c test.cpp ; echo $? 0 DKAdmin@ubik /tmp/boost $
> Can you attach the preprocessed source you get from that build of the compiler Unfortunately not, because I assumed that the new compiler will work, so make install overwritten the binaries of 0115. Anyway, I think I have an earlier build somewhere (20100107) which also works, so I will provide you a preprocessed source from that version.
So, as a matter of fact, char16_t and char32_t normally work on cygwin too. Then, what the heck is boost doing?
(In reply to comment #17) > So, as a matter of fact, char16_t and char32_t normally work on cygwin too. Ah, hang on. I may have got some of my revision numbers mixed up there. (I have a number of objdirs lying around built at various times from the same sandbox.) Here are two fairly recent ones: $ /gnu/gcc/install-lto/opt/gcc-tools/bin/g++-4 -std=c++0x -c mpl_size_hpp.ii ; echo $? 0 $ /gnu/gcc/install-obj2/opt/gcc-tools/bin/g++-4 -std=c++0x -c mpl_size_hpp.ii ; echo $? In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/include_preproces sed.hpp:37:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/full_lambda.hpp:4 4, from /usr/include/boost_1_39_0/boost/mpl/lambda.hpp:22, from /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:20, from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: specialization of 'boost::mpl::aux::template_arity<boost::mpl::lambda< mpl_::na, mpl_::na> >' after instantiation /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: redefinition of 'struct boost::mpl::aux::template_arity<boost::mpl::la mbda<mpl_::na, mpl_::na> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::lambda<mpl_::na, mpl_::na> >' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: specialization of 'boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >' after instantiati on /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: redefinition of 'struct boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::iter_fold<> >' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:19:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: specializa tion of 'boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >' after i nstantiation /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: redefiniti on of 'struct boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::iterator_range<> >' In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19: 0, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: specialization o f 'boost::mpl::aux::template_arity<boost::mpl::distance<> >' after instantiation /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: redefinition of 'struct boost::mpl::aux::template_arity<boost::mpl::distance<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::distance<> >' In file included from br.cpp:2:0: /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: specialization of 'b oost::mpl::aux::template_arity<boost::mpl::size<> >' after instantiation /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: redefinition of 'str uct boost::mpl::aux::template_arity<boost::mpl::size<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::size<> >' 1 DKAdmin@ubik /tmp/boost $ /gnu/gcc/install-lto/opt/gcc-tools/bin/g++-4 -std=c++0x -c mpl_size_hpp.ii ; echo $? 0 DKAdmin@ubik /tmp/boost $ However, note there's still no problem with the wide char types.
> Then say that explicitly, *always*. Actually, > the complete command line is part of the requirements for PRs. Sorry, I misunderstood you. I use -std=gnu++0x in my actual program, which today became uncompilable. For the PR it was: g++ -std=gnu++0x br.cpp -I/usr/include/boost_1_39_0/ Without extensions enabled, merely: g++ br.cpp -I/usr/include/boost_1_39_0/ the compiler also emits an error list, however much shorter (it's probably what you see on Linux): specialization after instantiation.
(In reply to comment #18) > (In reply to comment #17) > > So, as a matter of fact, char16_t and char32_t normally work on cygwin too. > > Ah, hang on. I may have got some of my revision numbers mixed up there. (I > have a number of objdirs lying around built at various times from the same > sandbox.) > > Here are two fairly recent ones: Those versions are: gcc version 4.5.0 20100121 (experimental) (GCC) gcc version 4.5.0 20100125 (experimental) (GCC) So I can confirm the specialisation error that you've also seen on x86_64-linux has also appeared on cygwin, but I can't yet confirm any bug about the char types.
Excellent Dave. Thus, we are looking for confirmation of the char16_t / char32_t issue, we don't see it on our cygwin and linux machines. And we should nail down more precisely in time the specialization / redefinition issue, can be a regression or g++ becoming more strict.
(In reply to comment #21) > Excellent Dave. Thus, we are looking for confirmation of the char16_t / > char32_t issue, we don't see it on our cygwin and linux machines. OK, so I'll try updating my most recent build from 156219 to 156253 and see if that makes a difference re. the char types.
cmdline: g++ [-std=gnu++0x] br.cpp -I/usr/include/boost_1_39_0/ On gcc version 4.5.0 20090604 (experimental) (GCC): compiled OK On gcc version 4.5.0 20100107 (experimental) (GCC) compiled OK On 20100115 it was also OK, but I can't prove it. On 20100126: a lot of errors, the amount depends on the presence of -std=gnu++0x I have no intermediate builds between 15 and 26, so can't reduce the range any more.
Created attachment 19727 [details] preprocessed boost 1.39 mpl/size.hpp (20100107)
(In reply to comment #24) > Created an attachment (id=19727) [edit] > preprocessed boost 1.39 mpl/size.hpp (20100107) > Apart from include file paths in # lines, the two files are identical.
> Apart from include file paths in # lines, the two files are identical. I double-checked the compilers used to generate them -- the attachments are correct. So the issue must be inside the compiler itself, not in its stdc++ includes.
(In reply to comment #26) > > Apart from include file paths in # lines, the two files are identical. > > I double-checked the compilers used to generate > them -- the attachments are correct. So the issue > must be inside the compiler itself, not in its > stdc++ includes. Indeed, and that matches what Paolo said in comment 13. I've now built r.156253 and here is the output from compiling your testcase; it still shows no sign of the charXX_t problem: $ /gnu/gcc/install-obj3/opt/gcc-tools/bin/g++-4 -std=c++0x o.cpp In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/include_preproces sed.hpp:37:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/full_lambda.hpp:4 4, from /usr/include/boost_1_39_0/boost/mpl/lambda.hpp:22, from /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:20, from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: specialization of 'boost::mpl::aux::template_arity<boost::mpl::lambda< mpl_::na, mpl_::na> >' after instantiation /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49 2: error: redefinition of 'struct boost::mpl::aux::template_arity<boost::mpl::la mbda<mpl_::na, mpl_::na> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::lambda<mpl_::na, mpl_::na> >' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: specialization of 'boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >' after instantiati on /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: redefinition of 'struct boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::iter_fold<> >' In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:19:0, from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: specializa tion of 'boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >' after i nstantiation /usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error: redefiniti on of 'struct boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::iterator_range<> >' In file included from /usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19: 0, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19, from br.cpp:2: /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: specialization o f 'boost::mpl::aux::template_arity<boost::mpl::distance<> >' after instantiation /usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: redefinition of 'struct boost::mpl::aux::template_arity<boost::mpl::distance<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::distance<> >' In file included from br.cpp:2:0: /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: specialization of 'b oost::mpl::aux::template_arity<boost::mpl::size<> >' after instantiation /usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: redefinition of 'str uct boost::mpl::aux::template_arity<boost::mpl::size<> >' /usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92: 1: error: previous definition of 'struct boost::mpl::aux::template_arity<boost:: mpl::size<> >' DKAdmin@ubik /tmp/boost $ .... except, of course, if I omit -std=c++0x: $ /gnu/gcc/install-obj3/opt/gcc-tools/bin/g++-4 o.cpp In file included from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/ty pe_traits:51:0, from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bi ts/move.h:38, from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bi ts/stl_pair.h:60, from /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/ut ility:71, from /usr/include/boost_1_39_0/boost/config/no_tr1/utility.hpp: 21, from /usr/include/boost_1_39_0/boost/config/select_stdlib_confi g.hpp:20, from /usr/include/boost_1_39_0/boost/config.hpp:40, from /usr/include/boost_1_39_0/boost/mpl/aux_/config/msvc.hpp:1 9, from /usr/include/boost_1_39_0/boost/mpl/aux_/config/adl.hpp:17 , from /usr/include/boost_1_39_0/boost/mpl/aux_/adl_barrier.hpp:1 7, from /usr/include/boost_1_39_0/boost/mpl/bool_fwd.hpp:17, from /usr/include/boost_1_39_0/boost/mpl/bool.hpp:17, from /usr/include/boost_1_39_0/boost/mpl/has_xxx.hpp:18, from /usr/include/boost_1_39_0/boost/mpl/aux_/has_tag.hpp:17, from /usr/include/boost_1_39_0/boost/mpl/sequence_tag.hpp:18, from /usr/include/boost_1_39_0/boost/mpl/size.hpp:18, from br.cpp:2: /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:112 :42: error: 'char16_t' was not declared in this scope /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:112 :50: error: template argument 1 is invalid /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:113 :42: error: 'char32_t' was not declared in this scope /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:113 :50: error: template argument 1 is invalid So, the bug is that it #includes tr1_impl even if the compiler is not in c++0x mode perhaps? It appears to be coming from the regular type_traits header: # 1 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/stddef.h" 1 3 4 # 45 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/cstddef" 2 3 # 43 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/type_traits" 2 3 # 51 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/type_traits" 3 # 1 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits" 1 3 # 30 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits" 3 namespace std { # 43 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits" Hmmm. That comes from here: 44 #if defined(_GLIBCXX_INCLUDE_AS_CXX0X) 45 # include <tr1_impl/type_traits> 46 #else 47 # define _GLIBCXX_INCLUDE_AS_CXX0X 48 # define _GLIBCXX_BEGIN_NAMESPACE_TR1 49 # define _GLIBCXX_END_NAMESPACE_TR1 50 # define _GLIBCXX_TR1 51 # include <tr1_impl/type_traits> 52 # undef _GLIBCXX_TR1 53 # undef _GLIBCXX_END_NAMESPACE_TR1 54 # undef _GLIBCXX_BEGIN_NAMESPACE_TR1 55 # undef _GLIBCXX_INCLUDE_AS_CXX0X 56 #endif and then tr1_impl/type_traits has: 111 #ifdef _GLIBCXX_INCLUDE_AS_CXX0X 112 _DEFINE_SPEC(0, __is_integral_helper, char16_t, true) 113 _DEFINE_SPEC(0, __is_integral_helper, char32_t, true) 114 #endif That kind of looks peculiar to me, but I don't know how the libstdc headers are put together. But why would we #define _GLIBCXX_INCLUDE_AS_CXX0X when we're not in C++0x mode?
I've just gone back through the older compiler versions I have lying around. None of them can successfully compile the testcase without -std=c++0x at all, they all complain about the missing types in the same way. So I think the stuff to do with char types is just a red-herring that happened while Piotr was trying out the standalone testcase, by omitting the -std flag.
To be clear: when the tr1_impl/type_traits implementation code is included as tr1 code, is included from <tr1/type_traits> that is, _GLIBCXX_INCLUDE_AS_CXX0X is undefined and no error should happen. Likewise, when the tr1_impl/type_traits code is included as C++0x code, from <type_traits> that is, the macro is defined, but no problem should occur in that case too because char16_t and char32_t are certainly available in C++0x mode. In practice, on linux I can compile the provided one-line snippet, both with -std=c++0x and without, and get *only* the errors unrelated to char16_t / char32_t. This doesn't suprise me, because in the libstdc++ testsuite we are *very* careful about these things: we have tons of testcases including <type_traits> and <tr1/type_traits> in normal mode, c++0x mode, etc.
If Dave, you have evidence that older versions of GCC always needed -std=c++0x in order to compile this boost code, this is a cygwin-specific issue: I just tried with a 4.4.x gcc and I can compile it without -std=c++0x.
(In reply to comment #30) > If Dave, you have evidence that older versions of GCC always needed -std=c++0x > in order to compile this boost code, this is a cygwin-specific issue: I just > tried with a 4.4.x gcc and I can compile it without -std=c++0x. This is 4.3.4, the stock cygwin distro version right now: DKAdmin@ubik /tmp/boost $ cat test.cpp char16_t a; DKAdmin@ubik /tmp/boost $ g++ -c test.cpp test.cpp:1: error: 'char16_t' does not name a type DKAdmin@ubik /tmp/boost $ g++ -c test.cpp -std=c++0x test.cpp:1: error: 'char16_t' does not name a type DKAdmin@ubik /tmp/boost I take it that much is unsurprising? This is the oldest version of trunk I have lying around, from r155967: DKAdmin@ubik /tmp/boost $ /gnu/gcc/install-clean/opt/gcc-tools/bin/g++-4 -c test.cpp test.cpp:1:1: error: 'char16_t' does not name a type DKAdmin@ubik /tmp/boost $ /gnu/gcc/install-clean/opt/gcc-tools/bin/g++-4 -c test.cpp -std=c++0x DKAdmin@ubik /tmp/boost That is also how everything up to r156253 behaves. Is there something wrong with that?
Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really honest, personally I'm not interested in cygwin much. My suggestion is just making sure the C++ front-end is fine for cygwin vs char16_t / char32_t, ans simply running the C++ testsuite should be more than enough. If eventually you come to the conclusion that some special workrounds in the C++ runtime is needed to support cygwin, let's discuss that separately.
(In reply to comment #32) > Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really > honest, personally I'm not interested in cygwin much. My suggestion is just > making sure the C++ front-end is fine for cygwin vs char16_t / char32_t, ans > simply running the C++ testsuite should be more than enough. If eventually you > come to the conclusion that some special workrounds in the C++ runtime is > needed to support cygwin, let's discuss that separately. I'll run the testsuite on today's build and see if it differs from my most recent run, which was pretty clean. More later when that finishes. (I thought the problem was that the preprocessed testcase was prepared using -std=c++0x and therefore embeds all the #ifdef decisions made using that standard, and so the preprocessed testcase must be compiled using the same -std= which was used to prepare it.)
Right Dave, that's why we ask submitters to also provide the actual command line used. Anyway, sorry about a bit of harshness on my side, I'm afraid we are 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. This is what I consider sane behavior modulo the *possible*, yet to be confirmed, C++ front-end issue with specialization / redefinition.
(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.
I removed the compiler error output, as misleading.
Actually, I'm going to remove all the preprocessed files too. Please attach a version built without -std=c++0x on the command line, the issue, if one exists, has absolutely nothing to do with c++0x.
Thanks Dave, we are fully on the same page now.
looks as though the .ii was created using -std=c++0x and then the compiler output obtained by compiling it without -std=c++0x that's never going to work
(In reply to comment #39) > looks as though the .ii was created using -std=c++0x and then the compiler > output obtained by compiling it without -std=c++0x > > that's never going to work > :) Yeah, I finally got there sometime around comment 33. I'll be ducking out of this one now, unless anyone needs me. Cheers all!
Created attachment 19731 [details] preprocessed on x86_64-linux In case somebody wants to play with it immediately, and doesn't have boost at hand, I'm attaching a .ii created on x86_64-linux (boost 1.39), the issue in any case doesn't have anything special to do with cygwin.
It is caused by revision 156106: http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00573.html
Created attachment 19738 [details] A somewhat reduced test case. This is a reduced test case, just in case.
This actually looks like another instance of PR c++/42758. *** This bug has been marked as a duplicate of 42758 ***
Thanks HJ and Dodji.
Subject: Bug 42880 Author: jason Date: Thu Jan 28 22:52:36 2010 New Revision: 156336 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156336 Log: PR c++/42880 * semantics.c (begin_class_definition): Don't use type_as_string. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
Subject: Bug 42880 Author: dodji Date: Fri Jan 29 14:30:41 2010 New Revision: 156351 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351 Log: Fix PRs c++/42758, c++/42634, c++/42797 ... and mitigate PR c++/42336 gcc/cp/ChangeLog: PR c++/42758 PR c++/42634 PR c++/42336 PR c++/42797 PR c++/42880 * cp-tree.h (NON_DEFAULT_TEMPLATE_ARGS_COUNT, SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT, GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): New accessor macros. * pt.c (coerce_template_parms, type_unification_real, expand_template_argument_pack, coerce_template_parameter_pack): Set the non default template args count. (current_template_args): Always set non defaulted template args count when compiled with --enable-checking (tsubst_template_args, type_unification_real): Propagate the non defaulted template args count. * error.c (get_non_default_template_args_count): Renamed count_non_default_template_args into this. Don't calculate the non default template argument count anymore. Use the new accessor macros above to get it. (dump_template_argument_list, dump_type, dump_decl, dump_template_parms): Adjust. * parser.c (cp_parser_template_argument_list): Always set defaulted template args count when compiled with --enable-checking. gcc/testsuite/ChangeLog: PR c++/42758 PR c++/42634 PR c++/42336 PR c++/42797 PR c++/42880 * g++.dg/other/crash-5.C: New test. * g++.dg/other/crash-6.C: New test. * g++.dg/other/crash-7.C: New test. * g++.dg/other/crash-8.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/crash-5.C trunk/gcc/testsuite/g++.dg/other/crash-6.C trunk/gcc/testsuite/g++.dg/other/crash-7.C trunk/gcc/testsuite/g++.dg/other/crash-8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/error.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 42880 Author: hjl Date: Sun Feb 7 04:41:22 2010 New Revision: 156562 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156562 Log: Backport testcases from mainline to 4.4. 2010-02-06 H.J. Lu <hongjiu.lu@intel.com> Backport from mainline: 2010-02-05 Dodji Seketeli <dodji@redhat.com> PR c++/42915 * g++.dg/other/crash-9.C: New test. 2010-02-03 Jason Merrill <jason@redhat.com> PR c++/40138 * g++.dg/ext/builtin11.C: New. 2010-02-03 Richard Guenther <rguenther@suse.de> PR tree-optimization/42944 * gcc.dg/errno-1.c: New testcase. 2010-02-03 Richard Guenther <rguenther@suse.de> PR middle-end/42927 * gcc.c-torture/compile/pr42927.c: New testcase. 2010-01-29 Dodji Seketeli <dodji@redhat.com> PR c++/42758 PR c++/42634 PR c++/42336 PR c++/42797 PR c++/42880 * g++.dg/other/crash-5.C: New test. * g++.dg/other/crash-7.C: New test. * g++.dg/other/crash-8.C: New test. 2010-01-28 Uros Bizjak <ubizjak@gmail.com> PR target/42891 * gcc.target/i386/pr42891.c: New test. 2010-01-28 Richard Guenther <rguenther@suse.de> PR middle-end/42883 * g++.dg/torture/pr42883.C: New testcase. 2010-01-28 Michael Matz <matz@suse.de> * gcc.target/i386/pr42881.c: New test. 2010-01-28 Dodji Seketeli <dodji@redhat.com> PR c++/42713 PR c++/42820 * g++.dg/template/typedef27.C: New test case. * g++.dg/template/typedef28.C: New test case. 2010-01-27 Jakub Jelinek <jakub@redhat.com> PR middle-end/42874 * gcc.dg/vla-22.c: New test. 2010-01-26 Richard Guenther <rguenther@suse.de> PR tree-optimization/42250 * gcc.dg/pr42250.c: New testcase. 2010-01-25 Tobias Burnus <burnus@net-b.de> PR fortran/42858 * gfortran.dg/generic_21.f90: New test. 2010-01-21 Martin Jambor <mjambor@suse.cz> PR tree-optimization/42585 * gcc.dg/tree-ssa/pr42585.c: New test. 2010-01-20 Alexandre Oliva <aoliva@redhat.com> PR debug/42715 * gcc.dg/pr42715.c: New. 2010-01-20 Richard Guenther <rguenther@suse.de> PR tree-optimization/42717 * gcc.c-torture/compile/pr42717.c: New testcase. 2010-01-19 Paul Thomas <pault@gcc.gnu.org> PR fortran/42783 * gfortran.dg/bounds_check_15.f90 : New test. 2010-01-18 Dodji Seketeli <dodji@redhat.com> PR c++/42766 * g++.dg/conversion/op6.C: New test. 2010-01-18 Richard Guenther <rguenther@suse.de> PR tree-optimization/42781 * gfortran.fortran-torture/compile/pr42781.f90: New testcase. 2010-01-17 Richard Guenther <rguenther@suse.de> PR middle-end/42248 * gcc.c-torture/execute/pr42248.c: New testcase. 2010-01-17 Janus Weil <janus@gcc.gnu.org> PR fortran/42677 * gfortran.dg/interface_assignment_5.f90: New test. 2010-01-15 Richard Guenther <rguenther@suse.de> PR middle-end/42739 * g++.dg/torture/pr42739.C: New testcase. 2010-01-14 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/42684 * gfortran.dg/interface_31.f90: New test. 2010-01-14 Martin Jambor <mjambor@suse.cz> PR tree-optimization/42706 * gcc.dg/ipa/pr42706.c: New testcase. 2010-01-14 Martin Jambor <mjambor@suse.cz> PR tree-optimization/42714 * g++.dg/torture/pr42714.C: New test. 2010-01-14 Alexander Monakov <amonakov@ispras.ru> PR rtl-optimization/42388 * gcc.dg/pr42388.c: New. 2010-01-14 Alexander Monakov <amonakov@ispras.ru> PR rtl-optimization/42294 * gfortran.dg/pr42294.f: New. 2010-01-14 Ira Rosen <irar@il.ibm.com> PR tree-optimization/42709 * gcc.dg/vect/pr42709.c: New test. 2010-01-13 Richard Guenther <rguenther@suse.de> PR tree-optimization/42730 * gcc.c-torture/compile/pr42730.c: New testcase. 2010-01-13 Martin Jambor <mjambor@suse.cz> PR tree-optimization/42704 * g++.dg/torture/pr42704.C: New test. 2010-01-13 Martin Jambor <mjambor@suse.cz> PR tree-optimization/42703 * gcc.c-torture/compile/pr42703.c: New test. 2010-01-13 Richard Guenther <rguenther@suse.de> PR tree-optimization/42705 * gcc.c-torture/compile/pr42705.c: New testcase. 2010-01-13 Richard Guenther <rguenther@suse.de> PR middle-end/42716 * gcc.c-torture/compile/pr42716.c: New testcase. 2010-01-12 Joseph Myers <joseph@codesourcery.com> PR c/42708 * gcc.c-torture/compile/pr42708-1.c: New test. 2010-01-09 Alexandre Oliva <aoliva@redhat.com> PR middle-end/42363 * gcc.dg/torture/pr42363.c: New. 2010-01-09 Alexandre Oliva <aoliva@redhat.com> PR debug/42604 PR debug/42395 * gcc.dg/vect/pr42604.c: New. * gcc.dg/vect/pr42395.c: New. 2010-01-09 Richard Guenther <rguenther@suse.de> PR middle-end/42512 * gcc.c-torture/execute/pr42512.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/conversion/op6.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/conversion/op6.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/builtin11.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/ext/builtin11.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-5.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/other/crash-5.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-7.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/other/crash-7.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-8.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/other/crash-8.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-9.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/other/crash-9.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef27.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/template/typedef27.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef28.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/template/typedef28.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42704.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/torture/pr42704.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42714.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/torture/pr42714.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42739.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/torture/pr42739.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42883.C - copied unchanged from r156561, trunk/gcc/testsuite/g++.dg/torture/pr42883.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42703.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/compile/pr42703.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42705.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/compile/pr42705.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42716.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/compile/pr42716.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42717.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/compile/pr42717.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42730.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/compile/pr42730.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42927.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/compile/pr42927.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42248.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/execute/pr42248.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42512.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/errno-1.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/errno-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/ipa/pr42706.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/ipa/pr42706.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42250.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42250.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42388.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42388.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42715.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42715.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42363.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/torture/pr42363.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42395.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vect/pr42395.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42604.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vect/pr42604.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42709.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vect/pr42709.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vla-22.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vla-22.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42881.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.target/i386/pr42881.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42891.c - copied unchanged from r156561, trunk/gcc/testsuite/gcc.target/i386/pr42891.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/bounds_check_15.f90 - copied unchanged from r156561, trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/generic_21.f90 - copied unchanged from r156561, trunk/gcc/testsuite/gfortran.dg/generic_21.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_31.f90 - copied unchanged from r156561, trunk/gcc/testsuite/gfortran.dg/interface_31.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_assignment_5.f90 - copied unchanged from r156561, trunk/gcc/testsuite/gfortran.dg/interface_assignment_5.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr42294.f - copied unchanged from r156561, trunk/gcc/testsuite/gfortran.dg/pr42294.f branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90 - copied unchanged from r156561, trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog