Boost regression notification (2005-10-26 [RC_1_33_0])
Boost regression test failures ------------------------------ Report time: 2005-10-26T14:54:08Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/is... 82 failures in 3 libraries: parameter (1) range (3) serialization (78) |parameter| tutorial: gcc-2.95.3-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin mingw-3_4_2 test_shared_ptr_132_text_warchive: intel-win32-8_1
On Oct 26, 2005, at 12:00 PM, Douglas Gregor wrote:
|serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin mingw-3_4_2 test_shared_ptr_132_text_warchive: intel-win32-8_1
Eeep! The looks like more dependency issues, but it's hard to tell what's going on. Help? Doug
Doug Gregor wrote:
On Oct 26, 2005, at 12:00 PM, Douglas Gregor wrote:
|serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin mingw-3_4_2 test_shared_ptr_132_text_warchive: intel-win32-8_1
Eeep! The looks like more dependency issues, but it's hard to tell what's going on. Help?
1) The cw-9_5-darwin failures are because some of the save tests failed. And since _all_ the load tests depend on _all_ the save tests it doesn't bother running them. 2) The rest I think are bogus errors as: a) the save tests pass for them and hence isn't issue (1); b) when one looks at the tests they point to other toolsets or errors (this is likely the strange delay processing errors we've seen before); and c) for similar configurations, i.e. the Bronek mingw-3.4.2 tests and my RSI mingw-3.4.2 test, fail on one and pass on the other the only difference being my tests are more recent. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
It does not really regex library issue, but the bug in hpux.hpp configuration header was revealed by regex library test regex_regress_threaded. Also, John Maddock is one of the authors of hpux.hpp, so, I thought, putting [regex] on the subject of this mail would be appropriate. Attached patch enables threads support on HP-UX when compiled with aCC. With patched header, test regex_regress_threaded passes. With the original header, it fails to compile. The patch also enables native swprintf and cwctype when _INCLUDE__STDC_A1_SOURCE macro is defined (on ia64, aCC predefines this macro). The hpux.hpp header is the same in RC_1_34 and HEAD and I'd like the patch to be committed to both, if possible. Thanks, Boris Gubenko HP C++ team $ diff hpux.hpp \ ./boost-RC_1_34_0-06-08-20-0308/boost/config/platform/hpux.hpp 5d4 < // (C) Copyright Boris Gubenko 2006. 22,25c21,22 < #if !(defined(__HP_aCC) && defined(_INCLUDE__STDC_A1_SOURCE)) < # define BOOST_NO_SWPRINTF < # define BOOST_NO_CWCTYPE < #endif ---
#define BOOST_NO_SWPRINTF #define BOOST_NO_CWCTYPE 36,38d32 < #elif defined(__HP_aCC) && !defined(BOOST_DISABLE_THREADS) < # define BOOST_HAS_THREADS < # define BOOST_HAS_PTHREADS $
Boris Gubenko wrote:
The patch also enables native swprintf and cwctype when _INCLUDE__STDC_A1_SOURCE macro is defined (on ia64, aCC predefines this macro).
The hpux.hpp header is the same in RC_1_34 and HEAD and I'd like the patch to be committed to both, if possible.
Will do, but shouldn't
< #if !(defined(__HP_aCC) && defined(_INCLUDE__STDC_A1_SOURCE)) < # define BOOST_NO_SWPRINTF < # define BOOST_NO_CWCTYPE < #endif
Be #if !(defined(__HP_aCC) && !defined(_INCLUDE__STDC_A1_SOURCE)) ? Thanks, John.
John Maddock wrote:
Will do, but shouldn't
Thank you!
< #if !(defined(__HP_aCC) && defined(_INCLUDE__STDC_A1_SOURCE)) < # define BOOST_NO_SWPRINTF < # define BOOST_NO_CWCTYPE < #endif
Be #if !(defined(__HP_aCC) && !defined(_INCLUDE__STDC_A1_SOURCE)) ?
No, I don't think so. The original condition says: don't define BOOST_NO_SWPRINTF and BOOST_NO_CWCTYPE macros when compiling with aCC with _INCLUDE__STDC_A1_SOURCE macro defined. This macro exposes I18N features added in 11i. On appropriate platforms, aCC predefines this macro. Thanks again, Boris ----- Original Message ----- From: "John Maddock" <john@johnmaddock.co.uk> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Tuesday, August 22, 2006 12:41 PM Subject: Re: [boost] [regex] patch for config/platform/hpux.hpp
Boris Gubenko wrote:
The patch also enables native swprintf and cwctype when _INCLUDE__STDC_A1_SOURCE macro is defined (on ia64, aCC predefines this macro).
The hpux.hpp header is the same in RC_1_34 and HEAD and I'd like the patch to be committed to both, if possible.
Will do, but shouldn't
< #if !(defined(__HP_aCC) && defined(_INCLUDE__STDC_A1_SOURCE)) < # define BOOST_NO_SWPRINTF < # define BOOST_NO_CWCTYPE < #endif
Be #if !(defined(__HP_aCC) && !defined(_INCLUDE__STDC_A1_SOURCE)) ?
Thanks, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
John Maddock wrote:
Will do, but shouldn't
Thank you!
< #if !(defined(__HP_aCC) && defined(_INCLUDE__STDC_A1_SOURCE)) < # define BOOST_NO_SWPRINTF < # define BOOST_NO_CWCTYPE < #endif
Be #if !(defined(__HP_aCC) && !defined(_INCLUDE__STDC_A1_SOURCE)) ?
No, I don't think so. The original condition says: don't define BOOST_NO_SWPRINTF and BOOST_NO_CWCTYPE macros when compiling with aCC with _INCLUDE__STDC_A1_SOURCE macro defined. This macro exposes I18N features added in 11i. On appropriate platforms, aCC predefines this macro.
Right, so if _INCLUDE__STDC_A1_SOURCE *is* defined, you *don't* want that pp-branch taken, so I still think it should be && !defined(_INCLUDE__STDC_A1_SOURCE) :-) Still confused yours, John.
Perhaps, I don't understand what BOOST_NO_SWPRINTF macro is for. From what I can see in the configuration headers for other platforms, this macro is set if a platforms does not have native swprintf. On HP-UX, if the compiler predefines _INCLUDE__STDC_A1_SOURCE macro, it means, that the platform has native swprintf and in this case, BOOST_NO_SWPRINTF macro should not be defined. It was the intention of the original condition and a quick experiment shows, that it works as intended. Before the fix, hpux.hpp would define BOOST_NO_SWPRINTF macro unconditionally. After the fix, it does not define it if a platform has native swprintf. I'm sure I'm missing something, I just don't know what it is :-) x.cpp ----- #if !(defined(__HP_aCC) && defined(_INCLUDE__STDC_A1_SOURCE)) # define BOOST_NO_SWPRINTF #endif #ifdef BOOST_NO_SWPRINTF # error BOOST_NO_SWPRINTF is defined #else # error BOOST_NO_SWPRINTF is not defined #endif bash-3.00$ uname -a HP-UX granite B.11.23 U ia64 2207888362 unlimited-user license bash-3.00$ aCC -E x.cpp 2>&1 | grep \#error "x.cpp", line 8: error #2035: #error directive: BOOST_NO_SWPRINTF is not defined bash-3.00$ bash-2.03$ uname -a HP-UX cal-bear B.11.11 U 9000/800 149901597 unlimited-user license bash-2.03$ aCC -E x.cpp 2>&1 | grep \#error Error 119: "x.cpp", line 6 # #error BOOST_NO_SWPRINTF is defined bash-2.03$
Still confused yours, John.
Utterly confused, Boris ----- Original Message ----- From: "John Maddock" <john@johnmaddock.co.uk> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Wednesday, August 23, 2006 4:51 AM Subject: Re: [boost] [regex] patch for config/platform/hpux.hpp
Boris Gubenko wrote:
John Maddock wrote:
Will do, but shouldn't
Thank you!
< #if !(defined(__HP_aCC) && defined(_INCLUDE__STDC_A1_SOURCE)) < # define BOOST_NO_SWPRINTF < # define BOOST_NO_CWCTYPE < #endif
Be #if !(defined(__HP_aCC) && !defined(_INCLUDE__STDC_A1_SOURCE)) ?
No, I don't think so. The original condition says: don't define BOOST_NO_SWPRINTF and BOOST_NO_CWCTYPE macros when compiling with aCC with _INCLUDE__STDC_A1_SOURCE macro defined. This macro exposes I18N features added in 11i. On appropriate platforms, aCC predefines this macro.
Right, so if _INCLUDE__STDC_A1_SOURCE *is* defined, you *don't* want that pp-branch taken, so I still think it should be && !defined(_INCLUDE__STDC_A1_SOURCE) :-)
Still confused yours,
John.
Boris Gubenko wrote:
Before the fix, hpux.hpp would define BOOST_NO_SWPRINTF macro unconditionally. After the fix, it does not define it if a platform has native swprintf. I'm sure I'm missing something, I just don't know what it is :-)
Utterly confused,
Doh! I get it now: I hadn't spotted the () after the initial ! Now that I've got into a testdrive machine the fix I came up with was: !defined(__HP_aCC) || !defined(_INCLUDE__STDC_A1_SOURCE) which of course is logically the same as yours :-) It also looks as though most of the Boost.Config macros set for aCC on itanium can be removed, but I'm still testing. John.
Douglas Gregor wrote: [...] Failures in mingw-3.4.2 are actually failures of other toolset, namely como-vc71 . I do not know how they "moved" to mingw B.
On 10/26/05, Bronek Kozicki <brok@rubikon.pl> wrote:
Failures in mingw-3.4.2 are actually failures of other toolset, namely como-vc71 . I do not know how they "moved" to mingw
The same thing is (still) happening with sunpro-5_3-sunos failures appearing as gcc-3_4_3-sunos failures. http://tinyurl.com/aqacn I think it may have to do with changes that have been made to the Jamfiles recently. Hopefully this will clear up with today's run, otherwise I'll stop running the SunPRO compiler on this branch for tomorrow. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On 10/26/05, Bronek Kozicki <brok@rubikon.pl> wrote:
Failures in mingw-3.4.2 are actually failures of other toolset, namely como-vc71 . I do not know how they "moved" to mingw
The same thing is (still) happening with sunpro-5_3-sunos failures appearing as gcc-3_4_3-sunos failures.
I think it may have to do with changes that have been made to the Jamfiles recently. Hopefully this will clear up with today's run, otherwise I'll stop running the SunPRO compiler on this branch for tomorrow.
I will also stop running tests on como for the weekend if problem persists tomorrow B.
participants (1)
-
Boris Gubenko -
Bronek Kozicki -
Caleb Epstein -
Doug Gregor -
Douglas Gregor
-
John Maddock -
Rene Rivera