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