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.