Minimum GCC version for building glibc

[Torvald Riegel]

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.