Re: [boost] [regex] patch for config/platform/hpux.hpp
John, I just realized, that unless BOOST_STRICT_CONFIG macro is defined (which we don't), config/compiler/hp_acc.hpp defines BOOST_NO_SWPRINTF macro. So, even if hpux.hpp would not define this macro, hp_acc.hpp will. I think, that for now, we should leave part of the hpux.hpp header setting BOOST_NO_SWPRINTF and BOOST_NO_CWCTYPE macros alone because, almost certainly, tuning configuration macros for HP-UX/aCC will require a coordinated update of both hpux.hpp and hp_acc.hpp. I think, that for now, we should change hpux.hpp to only define THREADS macros for aCC (which is necessary for regex_regress_threaded and static_mutex_test regex library tests to pass): #if defined(__GNUC__) ... #elif defined(__HP_aCC) && !defined(BOOST_DISABLE_THREADS) # define BOOST_HAS_THREADS # define BOOST_HAS_PTHREADS #endif Thanks for your help, Boris ----- Original Message ----- From: "Boris Gubenko" <Boris.Gubenko@hp.com> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Tuesday, August 22, 2006 2:37 PM Subject: Re: [boost] [regex] patch for config/platform/hpux.hpp
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,
I just realized, that unless BOOST_STRICT_CONFIG macro is defined (which we don't), config/compiler/hp_acc.hpp defines BOOST_NO_SWPRINTF macro. So, even if hpux.hpp would not define this macro, hp_acc.hpp will.
I think, that for now, we should leave part of the hpux.hpp header setting BOOST_NO_SWPRINTF and BOOST_NO_CWCTYPE macros alone because, almost certainly, tuning configuration macros for HP-UX/aCC will require a coordinated update of both hpux.hpp and hp_acc.hpp.
hp_acc.hpp looks hopelessly out of date: I suspect we could get a lot more tests passing with an update. I was going to do just that, but the hp.testdrive servers appear to be down this morning :-( There are some aCC specific workarounds in the regex lib that could probably be removed for recent aCC compiler releases as well.
I think, that for now, we should change hpux.hpp to only define THREADS macros for aCC (which is necessary for regex_regress_threaded and static_mutex_test regex library tests to pass):
#if defined(__GNUC__) ... #elif defined(__HP_aCC) && !defined(BOOST_DISABLE_THREADS) # define BOOST_HAS_THREADS # define BOOST_HAS_PTHREADS #endif
Thinking again, I don't think BOOST_HAS_THREADS should be set unconditionally here: aCC sets _REENTRANT when being built with -mt right? If so then BOOST_HAS_THREADS should get turned on automatically when building in multithread-mode *only* in boost/config/suffix.hpp. It was the lack of BOOST_HAS_PTHREADS that prevented this mechanism kicking in previously. But it needs testing, and those testdrive machines are still down. We also need to check that the bjam toolset set's the right flags for multithread builds. John.
John Maddock wrote:
hp_acc.hpp looks hopelessly out of date: I suspect we could get a lot more tests passing with an update. I was going to do just that, but the hp.testdrive servers appear to be down this morning :-(
The machine is up and running now and, I suspect, you know that :-) If you can update hp_acc.hpp to reflect aCC6 compiler, it would be great. An unexpected help from an expert... This compiler is based on EDG 3.06. On the testdrive machine, the compiler is A.06.07. This version of aCC6 does not predefine __EDG__ and __EDG_VERSION__ macros which can confuse some boost configuration headers. More recent versions of aCC6 do predefine these macros. For boost testing, I'm using A.06.12. It predefines __EDG* macros and sets __HP_aCC to 61200. A.06.10 also predefines __EDG* macros and sets __HP_aCC to 61000. Perhaps, we can use (__HP_aCC >= 61000) as a condition for "modern" aCC6 compiler (available on ia64 only). I think, it would be a good idea to upgrade the compiler on the testdrive machine to latest and greatest. Would you agree?
There are some aCC specific workarounds in the regex lib that could probably be removed for recent aCC compiler releases as well.
Currently, with hpux.hpp setting the THREADS macros, there are two regex library tests failing on HP-UX: concept_check and regex_token_iterator_eg_2. Both fail to compile.
#elif defined(__HP_aCC) && !defined(BOOST_DISABLE_THREADS) # define BOOST_HAS_THREADS # define BOOST_HAS_PTHREADS #endif
Thinking again, I don't think BOOST_HAS_THREADS should be set unconditionally here: aCC sets _REENTRANT when being built with -mt right?
Right.
If so then BOOST_HAS_THREADS should get turned on automatically when building in multithread-mode *only* in boost/config/suffix.hpp. It was the lack of BOOST_HAS_PTHREADS that prevented this mechanism kicking in previously.
I modified hpux.hpp to set only BOOST_HAS_PTHREADS macro, ran tests regex_regress_threaded and static_mutex_test and they both passed. So, yes, you are right: only BOOST_HAS_PTHREADS was needed. I'll run the full tests with modified header later today. The results will be on the web sometime tomorrow (hopefully).
We also need to check that the bjam toolset set's the right flags for multithread builds.
I think, it does, boost/tools/build/v2/tools/acc.jam does set '-mt' flag: # Select the compiler name according to the threading model. flags acc CFLAGS <threading>multi : -mt ; flags acc LINKFLAGS <threading>multi : -mt ; Thanks for the help, 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 5:01 AM Subject: Re: [boost] [regex] patch for config/platform/hpux.hpp
Boris Gubenko wrote:
John,
I just realized, that unless BOOST_STRICT_CONFIG macro is defined (which we don't), config/compiler/hp_acc.hpp defines BOOST_NO_SWPRINTF macro. So, even if hpux.hpp would not define this macro, hp_acc.hpp will.
I think, that for now, we should leave part of the hpux.hpp header setting BOOST_NO_SWPRINTF and BOOST_NO_CWCTYPE macros alone because, almost certainly, tuning configuration macros for HP-UX/aCC will require a coordinated update of both hpux.hpp and hp_acc.hpp.
hp_acc.hpp looks hopelessly out of date: I suspect we could get a lot more tests passing with an update. I was going to do just that, but the hp.testdrive servers appear to be down this morning :-(
There are some aCC specific workarounds in the regex lib that could probably be removed for recent aCC compiler releases as well.
I think, that for now, we should change hpux.hpp to only define THREADS macros for aCC (which is necessary for regex_regress_threaded and static_mutex_test regex library tests to pass):
#if defined(__GNUC__) ... #elif defined(__HP_aCC) && !defined(BOOST_DISABLE_THREADS) # define BOOST_HAS_THREADS # define BOOST_HAS_PTHREADS #endif
Thinking again, I don't think BOOST_HAS_THREADS should be set unconditionally here: aCC sets _REENTRANT when being built with -mt right? If so then BOOST_HAS_THREADS should get turned on automatically when building in multithread-mode *only* in boost/config/suffix.hpp. It was the lack of BOOST_HAS_PTHREADS that prevented this mechanism kicking in previously. But it needs testing, and those testdrive machines are still down. We also need to check that the bjam toolset set's the right flags for multithread builds.
John.
Boris Gubenko wrote:
John Maddock wrote:
hp_acc.hpp looks hopelessly out of date: I suspect we could get a lot more tests passing with an update. I was going to do just that, but the hp.testdrive servers appear to be down this morning :-(
The machine is up and running now and, I suspect, you know that :-) If you can update hp_acc.hpp to reflect aCC6 compiler, it would be great. An unexpected help from an expert... This compiler is based on EDG 3.06.
On the testdrive machine, the compiler is A.06.07. This version of aCC6 does not predefine __EDG__ and __EDG_VERSION__ macros which can confuse some boost configuration headers. More recent versions of aCC6 do predefine these macros.
For boost testing, I'm using A.06.12. It predefines __EDG* macros and sets __HP_aCC to 61200. A.06.10 also predefines __EDG* macros and sets __HP_aCC to 61000. Perhaps, we can use (__HP_aCC >= 61000) as a condition for "modern" aCC6 compiler (available on ia64 only).
I think, it would be a good idea to upgrade the compiler on the testdrive machine to latest and greatest. Would you agree?
Fine by me, but you would probably know best what your customers want from those testdrive machines. It makes sense to show off your latest technology though :-)
There are some aCC specific workarounds in the regex lib that could probably be removed for recent aCC compiler releases as well.
Currently, with hpux.hpp setting the THREADS macros, there are two regex library tests failing on HP-UX: concept_check and regex_token_iterator_eg_2. Both fail to compile.
Yep, I've committed some fairly conservative changes to the release branch (isolated to the aCC config, and to regex). I've placed some rather more agressive changes in cvs HEAD: so that only those config macros that really do need to be defined are done so. To make this work I also had to update some workarounds in type-traits - there may be others I've missed, which is why this isn't going on the release branch - too great a chance of messing things up :-( With those changes there is only one regex failure: the concept_check one. That appears to be because std::basic_string constructor doesn't accept iterator types it doesn't know about? I'll let you investigate that one :-) There is also a problem I noticed with WCHAR_MAX and WCHAR_MIN, there are a couple of tests that use these in preproccessing directives, but these evaluate to a typecast on both HP-UX and Tru64, and so can't be used in pp-directives in C++, even though they can in C. If you have any clout with whoever is responsible for these, there is a trick that uses: #define WCHAR_MIN ((wchar_t)(+0)) which evaluates to 0+0 in a pp-directive, but a typecast in C++ code. All the best, John.
John Maddock wrote:
It makes sense to show off your latest technology though :-)
To show off technology :-), we'll install latest compiler on the testdrive machine in the next few days. The kit is in the works now.
Yep, I've committed some fairly conservative changes to the release branch (isolated to the aCC config, and to regex).
Thanks a lot! I'll start 1.34 tests later today. Yesterday testing ended with memory access violation in "Getting test case results out of..." phase. This is the first time it happens since I started regular testing in June and it looks scary. Anyway, the current tests results on the web are the old ones.
With those changes there is only one regex failure: the concept_check one. That appears to be because std::basic_string constructor doesn't accept iterator types it doesn't know about? I'll let you investigate that one :-)
Will do.
There is also a problem I noticed with WCHAR_MAX and WCHAR_MIN, there are a couple of tests that use these in preproccessing directives, but these evaluate to a typecast on both HP-UX and Tru64, and so can't be used in pp-directives in C++, even though they can in C. If you have any clout with whoever is responsible for these, there is a trick that uses:
#define WCHAR_MIN ((wchar_t)(+0))
which evaluates to 0+0 in a pp-directive, but a typecast in C++ code.
We can certainly change the header, but on HP-UX, we may have a solution which would not require it. There is the following code in /usr/include/wchar.h: /* C99 stds require WCHAR_MAX and WCHAR_MIN to be macros which can be used in #if constructs, hence, can't have casts Retaining the old macros for compatibility */ # if defined(_INCLUDE_STDC__SOURCE_199901) # define WCHAR_MAX UINT_MAX /* max value of an unsigned integer */ # define WCHAR_MIN 0 # else # define WCHAR_MAX (wchar_t)UINT_MAX /* max value of an unsigned integer */ # define WCHAR_MIN (wchar_t)0 # endif So, when compiling with _INCLUDE_STDC__SOURCE_199901 macro defined, you get macro definitions you want: bash-3.00$ cat > x.cpp #include <wchar.h> WCHAR_MIN WCHAR_MAX bash-3.00$ aCC -E x.cpp | grep "(wchar_t)" extern int wcwidth (wchar_t); extern wint_t putwchar (wchar_t); (wchar_t)0 (wchar_t)4294967295U bash-3.00$ aCC -E x.cpp -D_INCLUDE_STDC__SOURCE_199901 | grep "(wchar_t)" extern int wcwidth (wchar_t); extern wint_t putwchar (wchar_t); bash-3.00$ I'm not sure what the impact of defining _INCLUDE_STDC__SOURCE_199901 macro in a C++ compilation is: I'll need to talk to other members of the team. If it is safe, we can define this macro in the boost configuration file for aCC. Or we can define it in those boost tests that assume "good" definitions. On Tru64, the compiler group owns cname headers, so, we can change <cwchar> and the change will be available in the next compiler release (no estimated date for the release yet). Changing <wchar.h> is possible, but the change will be available only in the next release of Tru64. Thanks a lot for your help. FYI: I'll be off tomorrow through next Tuesday with no access to email until Tuesday night. 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: Thursday, August 24, 2006 7:11 AM Subject: Re: [boost] [regex] patch for config/platform/hpux.hpp
Boris Gubenko wrote:
John Maddock wrote:
hp_acc.hpp looks hopelessly out of date: I suspect we could get a lot more tests passing with an update. I was going to do just that, but the hp.testdrive servers appear to be down this morning :-(
The machine is up and running now and, I suspect, you know that :-) If you can update hp_acc.hpp to reflect aCC6 compiler, it would be great. An unexpected help from an expert... This compiler is based on EDG 3.06.
On the testdrive machine, the compiler is A.06.07. This version of aCC6 does not predefine __EDG__ and __EDG_VERSION__ macros which can confuse some boost configuration headers. More recent versions of aCC6 do predefine these macros.
For boost testing, I'm using A.06.12. It predefines __EDG* macros and sets __HP_aCC to 61200. A.06.10 also predefines __EDG* macros and sets __HP_aCC to 61000. Perhaps, we can use (__HP_aCC >= 61000) as a condition for "modern" aCC6 compiler (available on ia64 only).
I think, it would be a good idea to upgrade the compiler on the testdrive machine to latest and greatest. Would you agree?
Fine by me, but you would probably know best what your customers want from those testdrive machines. It makes sense to show off your latest technology though :-)
There are some aCC specific workarounds in the regex lib that could probably be removed for recent aCC compiler releases as well.
Currently, with hpux.hpp setting the THREADS macros, there are two regex library tests failing on HP-UX: concept_check and regex_token_iterator_eg_2. Both fail to compile.
Yep, I've committed some fairly conservative changes to the release branch (isolated to the aCC config, and to regex). I've placed some rather more agressive changes in cvs HEAD: so that only those config macros that really do need to be defined are done so. To make this work I also had to update some workarounds in type-traits - there may be others I've missed, which is why this isn't going on the release branch - too great a chance of messing things up :-(
With those changes there is only one regex failure: the concept_check one. That appears to be because std::basic_string constructor doesn't accept iterator types it doesn't know about? I'll let you investigate that one :-)
There is also a problem I noticed with WCHAR_MAX and WCHAR_MIN, there are a couple of tests that use these in preproccessing directives, but these evaluate to a typecast on both HP-UX and Tru64, and so can't be used in pp-directives in C++, even though they can in C. If you have any clout with whoever is responsible for these, there is a trick that uses:
#define WCHAR_MIN ((wchar_t)(+0))
which evaluates to 0+0 in a pp-directive, but a typecast in C++ code.
All the best, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Boris Gubenko -
John Maddock