On 08/08/2011 03:47 PM, Rainer Orth wrote:
This patch moves gthr*.h and related code to toplevel libgcc.  Unlike
the other outstanding patches (libgcc1, libgcc2, crtstuff, shlib), it is
pretty independent from the rest, so I'm posting it first.  It was
developed last, so there may be conflicts (gcc/Makefile.in).  It also
depends on the posix95 removal patch.

Instead of cluttering the libgcc directory, all non-generic gthr-*.h
files were moved to their respecitive positions in libgcc/config.  The
patch simplifies gthr.h quite a bit:

* It does away with the need for thread-specific defines:

** HAVE_GTHR_DEFAULT is removed, instead I always create gthr-default.h,
    even if only as a link to gthr-single.h.  That simplifies the calling
    runtime libs which don't need to re-determine that value.

That's a good cleanup.

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

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

The gthr*.h headers have GCC_GTHR_* guards right now.  With the move,
one might want to change them to LIBGCC_GTHR_*.  If so, one needs to adapt
libstdc++-v3/include/Makefile.am.  I haven't touched this yet.

No hurry.

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

   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.

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

Paolo

Reply via email to