GCC C++0x regression testing online
Hello fellow Boosters, GCC 4.3 will have an experimental C++0x mode containing several of the new features coming into the language. I have started nightly regression testing of Boost CVS HEAD on the current version of GCC 4.3 using this experimental mode. The "OSL5" tester will run nightly, and allow us to try out these new features within Boost. Of course, please use the new BOOST_HAS_* feature macros (described in the config library documentation for CVS HEAD) to test for specific features when using them in your Boost library. The compiler running these tests supports the following C++0x features: - Rvalue references - Right angle brackets - Default template arguments for function templates - Delegating constructors - decltype - Static assertions - C99 preprocessor - Variadic templates The version of GCC used in this tester is a patched version of the FSF GCC from their mainline (4.3) compiler, which I update periodically. For more information about the specific patches I have applied, see the OSL5 summary in the regression tests. For more information about the experimental C++0x mode in the upcoming GCC 4.3, see http://gcc.gnu.org/gcc-4.3/changes.html. Have fun! Cheers, Doug
Doug Gregor wrote:
Hello fellow Boosters,
GCC 4.3 will have an experimental C++0x mode containing several of the new features coming into the language. I have started nightly regression testing of Boost CVS HEAD on the current version of GCC 4.3 using this experimental mode. The "OSL5" tester will run nightly, and allow us to try out these new features within Boost.
This is going to be very useful, thanks Doug. From the regression reports (http://tinyurl.com/2uvxrz), I see this version of GCC is not happy at all with xpressive. There are at least two problems: In file included from ../boost/detail/atomic_count.hpp:97, from ../boost/xpressive/detail/utility/counted_base.hpp:12, from ../boost/xpressive/detail/dynamic/matchable.hpp:21, from ../boost/xpressive/detail/core/access.hpp:18, from ../boost/xpressive/detail/core/state.hpp:18, from ../boost/xpressive/regex_algorithms.hpp:21, from ../libs/xpressive/test/test_regex_algorithms.cpp:8: ../boost/detail/atomic_count_gcc.hpp:20:28: error: bits/atomicity.h: No such file or directory This could be that the test machine is misconfigured, or that atomic_count.hpp needs a patch for this version of GCC. The other problem is: ../boost/xpressive/detail/core/state.hpp:95: error: declaration of 'typedef struct boost::xpressive::detail::match_context<BidiIter> boost::xpressive::detail::match_state<BidiIter>::match_context' ../boost/xpressive/detail/core/state.hpp:33: error: changes meaning of 'match_context' from 'struct boost::xpressive::detail::match_context<BidiIter>' The code it's complaining about looks like: template<typename BidiIter> struct match_state : noncopyable { typedef BidiIter iterator; typedef core_access<BidiIter> access; typedef match_context<BidiIter> match_context; It seems this version of GCC doesn't like my typedef'ing of match_context<It> to match_context. I think this is a compiler bug. Where should I report this bug? -- Eric Niebler Boost Consulting www.boost-consulting.com
On Apr 27, 2007, at 1:47 PM, Eric Niebler wrote:
This is going to be very useful, thanks Doug. From the regression reports (http://tinyurl.com/2uvxrz), I see this version of GCC is not happy at all with xpressive. There are at least two problems:
In file included from ../boost/detail/atomic_count.hpp:97, from ../boost/xpressive/detail/utility/counted_base.hpp:12, from ../boost/xpressive/detail/dynamic/ matchable.hpp:21, from ../boost/xpressive/detail/core/access.hpp:18, from ../boost/xpressive/detail/core/state.hpp:18, from ../boost/xpressive/regex_algorithms.hpp:21, from ../libs/xpressive/test/ test_regex_algorithms.cpp:8: ../boost/detail/atomic_count_gcc.hpp:20:28: error: bits/ atomicity.h: No such file or directory
This could be that the test machine is misconfigured, or that atomic_count.hpp needs a patch for this version of GCC.
GCC 4.3 has moved this header into ext/atomicity.h and all of its functions into namespace __gnu_cxx.
The other problem is: ../boost/xpressive/detail/core/state.hpp:95: error: declaration of 'typedef struct boost::xpressive::detail::match_context<BidiIter> boost::xpressive::detail::match_state<BidiIter>::match_context' ../boost/xpressive/detail/core/state.hpp:33: error: changes meaning of 'match_context' from 'struct boost::xpressive::detail::match_context<BidiIter>'
The code it's complaining about looks like:
template<typename BidiIter> struct match_state : noncopyable { typedef BidiIter iterator; typedef core_access<BidiIter> access; typedef match_context<BidiIter> match_context;
It seems this version of GCC doesn't like my typedef'ing of match_context<It> to match_context. I think this is a compiler bug.
Where should I report this bug?
The bug also occurs on mainline GCC 4.3 (without my changes), so please report it to the Bugzilla system on gcc.gnu.org. Here's a shorter test case: template<typename Iter> struct match_context { }; template<typename BidIter> struct match_state { typedef match_context<BidIter> match_context; }; - Doug
Doug Gregor wrote:
The other problem is: ../boost/xpressive/detail/core/state.hpp:95: error: declaration of 'typedef struct boost::xpressive::detail::match_context<BidiIter> boost::xpressive::detail::match_state<BidiIter>::match_context' ../boost/xpressive/detail/core/state.hpp:33: error: changes meaning of 'match_context' from 'struct boost::xpressive::detail::match_context<BidiIter>'
<snip>
The bug also occurs on mainline GCC 4.3 (without my changes), so please report it to the Bugzilla system on gcc.gnu.org. Here's a shorter test case:
template<typename Iter> struct match_context { };
template<typename BidIter> struct match_state { typedef match_context<BidIter> match_context; };
Huh, they say it's not a bug. ------- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-27 20:16 ------- No, the error message is correct. You change the meaning of match_context in the class. Doing: typedef ::match_context<BidIter> match_context; Fixes the source to be valid C++. Note C++ does not really require a diagnostic here (it is one of the invalid code that C++ does not require one). ---- Seems odd to me, but I don't have time to dig in the standard right now. GCC 4.3 is the only compiler that complains about this. Even Comeau accepts it. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Apr 27, 2007, at 3:24 PM, Eric Niebler wrote:
Huh, they say it's not a bug.
------- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-27 20:16 ------- No, the error message is correct. You change the meaning of match_context in the class.
Doing: typedef ::match_context<BidIter> match_context;
Fixes the source to be valid C++. Note C++ does not really require a diagnostic here (it is one of the invalid code that C++ does not require one). ----
Seems odd to me, but I don't have time to dig in the standard right now. GCC 4.3 is the only compiler that complains about this. Even Comeau accepts it.
Ah, they're right. This is the first paragraph of [basic.scope.class], which says: 2) A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule. I think that's the first time---ever---where I've seen GCC be more picky than EDG in strict mode :) - Doug
Doug Gregor wrote:
On Apr 27, 2007, at 1:47 PM, Eric Niebler wrote:
This is going to be very useful, thanks Doug. From the regression reports (http://tinyurl.com/2uvxrz), I see this version of GCC is not happy at all with xpressive. There are at least two problems:
In file included from ../boost/detail/atomic_count.hpp:97, from ../boost/xpressive/detail/utility/counted_base.hpp:12, from ../boost/xpressive/detail/dynamic/ matchable.hpp:21, from ../boost/xpressive/detail/core/access.hpp:18, from ../boost/xpressive/detail/core/state.hpp:18, from ../boost/xpressive/regex_algorithms.hpp:21, from ../libs/xpressive/test/ test_regex_algorithms.cpp:8: ../boost/detail/atomic_count_gcc.hpp:20:28: error: bits/ atomicity.h: No such file or directory
This could be that the test machine is misconfigured, or that atomic_count.hpp needs a patch for this version of GCC.
GCC 4.3 has moved this header into ext/atomicity.h and all of its functions into namespace __gnu_cxx.
For GCC 4.1 and above, we need to switch atomic_count and sp_counted_base to http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html If someone can submit a patch for that I'll incorporate it, otherwise it will happen whenever I find the time to implement and test it myself.
Peter Dimov wrote:
For GCC 4.1 and above, we need to switch atomic_count and sp_counted_base to
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
If someone can submit a patch for that I'll incorporate it, otherwise it will happen whenever I find the time to implement and test it myself.
That's more than I have time for, but the attached patch at least gets detail/atomic_count.hpp compiling again on gcc-4.3. OK to commit? -- Eric Niebler Boost Consulting www.boost-consulting.com Index: atomic_count_gcc.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/atomic_count_gcc.hpp,v retrieving revision 1.5 diff -b -d -u -r1.5 atomic_count_gcc.hpp --- atomic_count_gcc.hpp 2 Apr 2005 11:37:53 -0000 1.5 +++ atomic_count_gcc.hpp 28 Apr 2007 01:33:27 -0000 @@ -17,7 +17,11 @@ // http://www.boost.org/LICENSE_1_0.txt) // -#include <bits/atomicity.h> +#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 3)) +# include <ext/atomicity.h> +#else +# include <bits/atomicity.h> +#endif namespace boost {
Eric Niebler wrote:
Peter Dimov wrote:
For GCC 4.1 and above, we need to switch atomic_count and sp_counted_base to
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
If someone can submit a patch for that I'll incorporate it, otherwise it will happen whenever I find the time to implement and test it myself.
That's more than I have time for, but the attached patch at least gets detail/atomic_count.hpp compiling again on gcc-4.3. OK to commit?
Negative. I (think I) fixed it the right way.
Peter Dimov wrote:
Eric Niebler wrote:
Peter Dimov wrote:
For GCC 4.1 and above, we need to switch atomic_count and sp_counted_base to
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
If someone can submit a patch for that I'll incorporate it, otherwise it will happen whenever I find the time to implement and test it myself.
That's more than I have time for, but the attached patch at least gets detail/atomic_count.hpp compiling again on gcc-4.3. OK to commit?
Negative. I (think I) fixed it the right way.
Looks like this change is causing a linker error on at least one platform. http://tinyurl.com/2hccmr /home/cae/boost-regression/CVS-HEAD/results/boost/bin.v2/libs/xpressive/test/test3.test/gcc-4.1.1_sunos_i86pc/debug/debug-symbols-off/link-static/test3.o: In function `boost::detail::atomic_count::operator long() const': test3.cpp:(.text._ZNK5boost6detail12atomic_countcvlEv[boost::detail::atomic_count::operator long() const]+0x10): undefined reference to `__sync_fetch_and_add_4' /home/cae/boost-regression/CVS-HEAD/results/boost/bin.v2/libs/xpressive/test/test3.test/gcc-4.1.1_sunos_i86pc/debug/debug-symbols-off/link-static/test3.o: In function `boost::detail::atomic_count::operator--()': test3.cpp:(.text._ZN5boost6detail12atomic_countmmEv[boost::detail::atomic_count::operator--()]+0x10): undefined reference to `__sync_add_and_fetch_4' collect2: ld returned 1 exit status This is on gcc-4.1.1_sunos_i86pc. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Looks like this change is causing a linker error on at least one platform.
Why doesn't this platform appear in http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/xpressi... ?
Peter Dimov wrote:
Eric Niebler wrote:
Looks like this change is causing a linker error on at least one platform.
Why doesn't this platform appear in
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/xpressi...
?
It did just a moment ago. There's some bug in the test scripts that's causing this platform and the HP-UX one to appear and disappear at random. It's been reported on the test alias, but nobody has looked into it yet. Aleksey? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler writes:
Peter Dimov wrote:
Eric Niebler wrote:
Looks like this change is causing a linker error on at least one platform.
Why doesn't this platform appear in
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/xpressi...
?
It did just a moment ago. There's some bug in the test scripts that's causing this platform and the HP-UX one to appear and disappear at random. It's been reported on the test alias, but nobody has looked into it yet. Aleksey?
Fixed (starting from the next report pages update). -- Aleksey Gurtovoy MetaCommunications Engineering
Eric Niebler wrote:
Looks like this change is causing a linker error on at least one platform.
So this is the i386 problem (why is this the default for g++ in this day and age remains a mystery to me). We can fix it on the atomic_count side by supplying an assembly implementation that assumes 486+ regardless of the target, as is done with sp_counted_base. Or we can run the SunOS tests for i486 or better. Which one should be it?
Peter Dimov wrote:
Eric Niebler wrote:
Looks like this change is causing a linker error on at least one platform.
So this is the i386 problem (why is this the default for g++ in this day and age remains a mystery to me). We can fix it on the atomic_count side by supplying an assembly implementation that assumes 486+ regardless of the target, as is done with sp_counted_base. Or we can run the SunOS tests for i486 or better. Which one should be it?
I'm not familiar with "the i386 problem". Is there an easy way to reuse the solution for sp_counted_base? Seems to me like we should be consistent, but it's ultimately your call. Thanks for looking into this. -- Eric Niebler Boost Consulting www.boost-consulting.com
Hello Eric, Tuesday, May 8, 2007, 10:03:40 PM, you wrote:
Peter Dimov wrote:
Eric Niebler wrote:
Looks like this change is causing a linker error on at least one platform.
So this is the i386 problem (why is this the default for g++ in this day and age remains a mystery to me). We can fix it on the atomic_count side by supplying an assembly implementation that assumes 486+ regardless of the target, as is done with sp_counted_base. Or we can run the SunOS tests for i486 or better. Which one should be it?
I'm not familiar with "the i386 problem". Is there an easy way to reuse the solution for sp_counted_base? Seems to me like we should be consistent, but it's ultimately your call.
Why can't we use the old atomic_count and sp_counted_base implementations (i.e. asm, atomicity.h and interlocked functions)? -- Best regards, Andrey mailto:andysem@mail.ru
Hello Peter, Friday, April 27, 2007, 11:29:57 PM, you wrote:
This could be that the test machine is misconfigured, or that atomic_count.hpp needs a patch for this version of GCC.
GCC 4.3 has moved this header into ext/atomicity.h and all of its functions into namespace __gnu_cxx.
For GCC 4.1 and above, we need to switch atomic_count and sp_counted_base to
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
If someone can submit a patch for that I'll incorporate it, otherwise it will happen whenever I find the time to implement and test it myself.
Please note that if the target platform is not supported with these extensions, the compiler will generate external function call which will most likely result in link errors. For example, I tried to make use of them under Cygwin (I was hoping they would do just like interlocked functions) and got this problem. -- Best regards, Andrey mailto:andysem@mail.ru
Andrey Semashev wrote:
Hello Peter,
Friday, April 27, 2007, 11:29:57 PM, you wrote:
This could be that the test machine is misconfigured, or that atomic_count.hpp needs a patch for this version of GCC.
GCC 4.3 has moved this header into ext/atomicity.h and all of its functions into namespace __gnu_cxx.
For GCC 4.1 and above, we need to switch atomic_count and sp_counted_base to
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
If someone can submit a patch for that I'll incorporate it, otherwise it will happen whenever I find the time to implement and test it myself.
Please note that if the target platform is not supported with these extensions, the compiler will generate external function call which will most likely result in link errors. For example, I tried to make use of them under Cygwin (I was hoping they would do just like interlocked functions) and got this problem.
Cygwin works, you just need to compile for 486 or better.
Hello Peter, Thursday, May 3, 2007, 1:38:03 AM, you wrote:
Andrey Semashev wrote:
Hello Peter,
Friday, April 27, 2007, 11:29:57 PM, you wrote:
This could be that the test machine is misconfigured, or that atomic_count.hpp needs a patch for this version of GCC.
GCC 4.3 has moved this header into ext/atomicity.h and all of its functions into namespace __gnu_cxx.
For GCC 4.1 and above, we need to switch atomic_count and sp_counted_base to
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
If someone can submit a patch for that I'll incorporate it, otherwise it will happen whenever I find the time to implement and test it myself.
Please note that if the target platform is not supported with these extensions, the compiler will generate external function call which will most likely result in link errors. For example, I tried to make use of them under Cygwin (I was hoping they would do just like interlocked functions) and got this problem.
Cygwin works, you just need to compile for 486 or better.
Hm, I'll have to try (I thought there is no difference). But still the problem stays. If some platform is not supported by compiler in this way, users will get link errors. -- Best regards, Andrey mailto:andysem@mail.ru
participants (5)
-
Aleksey Gurtovoy -
Andrey Semashev -
Doug Gregor -
Eric Niebler -
Peter Dimov