This is the mail archive of the
mailing list for the glibc project.
Re: Minimum GCC version for building glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 5 Nov 2014 16:34:58 +0000
- 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>
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