Minimum GCC version for building glibc
Joseph Myers
joseph@codesourcery.com
Wed Nov 5 16:35:00 GMT 2014
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
More information about the Libc-alpha
mailing list