Paolo Bonzini <bonz...@gnu.org> writes:

>> ** The use of _PTHREADS to select gthr-posix.h is quite inconsistent:
>>     only a few targets define that macro (m32r/linux.h, mn10300/linux.h,
>>     netbsd.h, sh/linux.h, sol2.h), and none of them support alternative
>>     thread models.  Given that everything works fine for every other
>>     Linux target suggests that this can go.
>
> _PTHREADS is used in the wild, I'm not sure about removing it from the
> specs, especially for netbsd.h and sol2.h.

Given it's inconsistent definition across platforms and the fact that
it's an implementation artefact, I'd argue for removing it.  I've just
did a google search and there aren't too many uses, many of them
misguided or using constructs like defined(_REENTRANT) ||
defined(_PTHREADS) which continue to work.  Of course we should announce
this, together with the posix95 removal.

>> ** _DCE_THREADS is used to select gthr-dce.h, but again dce is the
>>     only/default model on hppa[12]*-*-hpux10* (pa-hpux10.h), so the
>>     special-casing can be removed.
>
> Agreed, but again I'm not sure about removing it from the spec.

I could find no use outside of gthr.h/gthr-dce.h, and the platform is
old (I may say so, being the keeper of historical OSes myself :-).

>> I noticed that config/t-vxworks installs gthr-vxworks.h, gthr-default.h
>> via EXTRA_HEADERS, but the comment suggests this is only for the benefit
>> of the runtime libs which know how to find them, so I've removed that.
>
> Looks good, but should also be added to changes.html.

Agreed.

>>    A really ugly point in the gthr.h interface is that all users need to
>>    define SUPPORTS_WEAK and GTHREAD_USE_WEAK themselves.  It would be far
>>    better to substitute the result of such a test into gthr.h to avoid
>>    this complication.
>
> Yes, and they can also be unified.  The advantage of toplevel libgcc move
> is that the configury becomes self-contained and it is "easy" to spot these
> historical problems...

Right: nobody in his right mind would look at this stuff otherwise :-)

>>    Currently, this is handled quite inconsistently: libobjc does nothing,
>>    libstdc++-v3/acinclude.m4 (GLIBCXX_CHECK_GTHREADS) hardcodes
>>    SUPPORTS_WEAK, GTHREAD_USE_WEAK for posix threads, and
>>    libgfortran/acinclude.m4 (LIBGFOR_GTHREAD_WEAK) tries to determine a
>>    sensible value.
>
> I think libgfortran's approach is the nicest to be added in
> libgcc/configure.ac.

I'm not convinced: when it was introduced (or used more extensively), I
was already bitten by the fact that the GTHREAD_USE_WEAK test uses a
hardcoded list, instead of really checking what it is meant to test:
support for weak definitions.  Perhaps the autoconf-archive macro is
better in this respect.

>> As I said, I'd like to handle this aspect in a followup patch and keep
>> the build part separate.
>
> That's fine.
>
> Let's wait for result of testing, especially Win32 (Kai?).

Certainly: this is far too risky with testing only on posix systems.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to