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

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <200105200043.UAA26358@hiauly1.hia.nrc.ca> you write:
> Here is a patch for review to correct various problems related to the
> configuration and use of threads with libstdc++-v3.

Nice effort but I agree some (major) tweaking is needed...

BTW, great timing as I just looked closely at these threading issues
in some detail recently (I have an unsubmitted patch that is for an
unrelated threading issue).

> A new configuration variable, THREADS_FLAGS, is introduced.  This
> sets `-pthread' when using posix threads. [...]

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'}'.

> 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?

> 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.

> I have done a complete bootstrap with these changes under i686 linux
> with posix threads and under hppa1.1-hp-hpux10.20 with dce threads.

Before your change could be applied, I think we would have to test it
against far more ports than this.

> 1) Sol2 on sparc and i386 uses `-pthreads'.  Is this a typo or just ...

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.

> 3) I imagine some further tweaking will be needed.

> OK?

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.

BTW, I have no authority to approve or deny your patch but I hope my
comments were useful.

Regards,
Loren