Re: [boost] [regex] patch for config/platform/hpux.hpp

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-08-23 15:28:36

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_at_[hidden]>
To: <boost_at_[hidden]>
Cc: "Boris Gubenko" <Boris.Gubenko_at_[hidden]>
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.
>