This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum GCC version for building glibc
- From: Torvald Riegel <triegel at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Wed, 05 Nov 2014 16:12:25 -0600
- Subject: Re: Minimum GCC version for building glibc
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1410311352200 dot 4263 at digraph dot polyomino dot org dot uk> <20141104165815 dot GK5402 at vapier dot wh0rd dot info> <5459239B dot 4020901 at cs dot ucla dot edu> <20141104214726 dot EF16D2C244F at topped-with-meat dot com> <1415158871 dot 4531 dot 60 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1411051629250 dot 1007 at digraph dot polyomino dot org dot uk>
On Wed, 2014-11-05 at 16:34 +0000, Joseph Myers wrote:
> On Tue, 4 Nov 2014, Torvald Riegel wrote:
>
> > Requiring 4.7 would start to become beneficial when it allows us to
> > remove the then unneeded code. This would be the case for x86, I guess,
> > and mips to a partial extent IIRC. But I don't really know how this
>
> It would at least fix bug 17404 for MIPS16.
>
> > would look for other archs, in particular at which GCC version the
> > atomics support on a particular arch becomes sufficient. I also haven't
>
> For the most commonly used architectures, 4.7 has the relevant support.
> (Avoiding the 4.7 support is mainly relevant if (a) the architecture
> supports the more precise memory order selection available with C11
> atomics, but (b) that support isn't in GCC 4.7 and 4.7 instead uses
> stronger than necessary barriers (like with __sync_*), so with 4.7 it's
> still better to use inline asm if available - like on MIPS.)
>
> > really looked at what to do when GCC's libatomic would implement certain
> > atomics (e.g., when the kernel is used) -- should we just use libatomic,
> > or would we need to keep rolling our own.
>
> My inclination is to keep rolling our own. I suspect libatomic might be
> troublesome in bootstrap builds (where the desire is for glibc built with
> an initial static-only GCC, itself built without C library headers, to be
> identical to glibc built from a longer iteration of alternating GCC and
> glibc builds).
Good point.
> And any libatomic operations based on locks (e.g. the
> operations for arbitrary-sized types) obviously aren't suitable for glibc
> use (depending as they do on pthread_mutex_lock).
Agreed. And libatomic doesn't seem to have direct ways to use the
kernel for atomics except on ARM.