Re: Minimum GCC version for building glibc

[Joseph Myers <joseph at codesourcery dot com>]

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

-- 
Joseph S. Myers
joseph@codesourcery.com