Re: PATCH: Re: eh_globals.cc compilation errors with -threads under hpux 10.20

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> As you observed in your issue section below, the -pthread option is
> not standardized across all ports.  This issue has been raised over
> the years.  The best idea I have is to retain all existing
> system-specific threading switches but ensure -pthread is supported
> for any platform that support POSIX threads.
>
> This step will clean up reams of port-specific configuration in
> various places around the gcc tree to handle threading support.  But
> you can't apply this patch which uses -pthread to libstdc++ until we
> standardize constructs in gcc/gcc/config/.../*.h.
>
> Anywhere we provide a spec component which keys off of a
> system-specific switch (e.g. -pthreads) which is an alias in terms of
> functionality for the new standardized -pthread, we can use:
> 
> `%{`S'|`P':`X'}'
> 
> instead of:
> 
> `%{`S':`X'}'
> 
> where S is the system-specific switch and P is -pthread.
> 
> I think to handle `%{!`S':`X'}', we use `%{!`S'|!`P':`X'}'.

This looks very reasonable to me.

> > The v3 file threads-posix.h is changed to not define _PTHREADS.  This
> > allows the file to also be used with DCE threads.  Definition of either
> > _PTHREADS or _REENTRANT by a backend will enable _STL_THREADS.
> 
> OK, this change will break *-*-freebsd* (and many other ports) since
> the -pthread option only arranges for linking to work properly, no
> preprocessing symbols are ever defined in light of that switch.  In
> fact, only Solaris on sparc and i386 and Linux on sh appear to define
> _PTHREADS when -pthread[s] was provided.
> 
> Since DCE threads doesn't want that symbol defined, shouldn't that
> configuration have a threads-dce.h file instead of attempting to use
> threads-posix.h?

See below.  If you decided to that continuing to define _PTHREADS 
in threads-posix.h is the best option, then introducing a threads-dce.h
file may be required.  Another option would be an ifdef around the define.

DCE threads under hpux 10.20 are an early implementation of posix threads.
Under hpux 11, I believe they meet the full posix spec, although I am far
from an expert on this.  I didn't want to introduce a new file unless
it was absolutely necessary.

> > The changes exposed problems in eh_globals.cc resulting from the eh
> > merge.  I made changed that enable successful compilation.  However,
> > these are not fully tested beyond the testing that occurs in the
> > V3 testsuite.  Note previously this code was not being compiled
> > at least on i686 linux because gthr-single.h was being included
> > instead of gthr-posix.h.
> 
> I am confused here.  Why was gthr-single.h being slected for linux (I
> assume that --enable-threads=posix was provided to the top-level
> configure or that is the default for linux)?  I am not seeing this
> problem on freebsd.

If you don't configure with --enable-threads=posix under i686 linux, then
I believe that the thread model is single even though gthr-default.h is a
link to gcc/gthr-posix.h.  As a result, the v3 configure uses threads-no.h.

I presume that nobody tested --enable-threads=posix under i686 linux
because the following define

// Currently needed for stl/bits/stl_config.h
# define _PTHREADS

in config/threads-posix.h causes a build error when gthr.h is included.
The check in gthr.h is `#if _PTHREADS' and not `if defined(_PTHREADS)'.
When the define is fixed, you find the additional code errors in
eh_globals.cc.

Since eh_globals.cc and eh_alloc.cc include gthr.h, it seemed logically
incorrect for threads-posix.h to override the defines provided by the
backends when -pthread(s) is specified.  In particular, _PTHREADS controls 
whether or not gthr-posix.h is included or not.  This led me to
decide it would be better delete the above define rather than change
it to 

# define _PTHREADS 1

I suggest that under freebsd you look carefully at the v3 configure output
regarding the thread model and the includes loaded when compiling
eh_globals.cc.  You probably don't have the thread routines that you
thought you had.

> No typo, just never been standardized completely.
> 
> > 2) Aix doesn't seem to define either _PTHREADS or _REENTRANT.  How
> >   does gthr.h include the right header for posix threads?
> 
> I don't understand this completely myself.  As far as I know, AIX is
> multilib'd in a way that it builds against the correct version of
> gcc/gc/gthr-*.h in each path.

The HPUX implementation is similar to that for AIX.  The build automatically
adds `-threads' when building the threaded libraries.  This also gives
the correct defines and linking.  You don't have to do anything special
for these systems.

> Please do not install this yet.  Can you do just enough to solve the
> problem for DCE by making a new threads-dce.h file and configure it
> in.  This way we don't have to chance breaking all other ports before
> the 3.0 release.  After the 3.0 release, let's fix the problem in a
> better way on mainline.

I have no problem being pragmatic about this for the branch.  I just
want to point out that the investigation that started from trying
to get things working with the multilib'd dce threads on hpux showed
that things are also broken for i686 linux, and probably other systems
as well.  Thus, it's my feeling that most ports are broken now.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)