This is the mail archive of the
mailing list for the glibc project.
Re: RFC: requiring GCC >= 4.7 to build glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 21 Aug 2015 15:44:59 +0000
- Subject: Re: RFC: requiring GCC >= 4.7 to build glibc
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1508201344140 dot 30940 at digraph dot polyomino dot org dot uk> <20150820161822 dot GH21236 at vapier> <alpine dot DEB dot 2 dot 10 dot 1508201623200 dot 30940 at digraph dot polyomino dot org dot uk> <20150821152302 dot GL21236 at vapier>
On Fri, 21 Aug 2015, Mike Frysinger wrote:
> > The idea is that the dead code is cleaned up incrementally after the main
> > diff does nothing beyond the version increases, not to prepare in advance
> > diffs that may or may not be needed....
> i'm aware of basic truisms (if we don't support X, then it means less work).
> i don't think that's relevant to the discussion. when someone says "i want to
> drop feature X", then imo they really need to provide concrete examples of what
> dropping that gains us.
I gave examples. I don't think preparing actual patches for them is
useful without consensus for the change.
I should add: my claim is that the value of supporting GCC 4.6 (ceased to
be maintained over two years ago) is low, low enough that miscellaneous
incremental improvements should be enough to justify removing that
support. We shouldn't expect an increase of one major compiler version to
bring in major cleanups; we should expect each such increase to bring in a
few such cleanups, that add up over the years, and should routinely
increase the minimum versions of GCC, binutils and the Linux kernel to
facilitate such cleanups.
(We moved to requiring binutils 2.22 or later for glibc 2.21, so I think
we could reasonably start requiring binutils 2.23 or later for glibc 2.23
although I'm not making a specific proposal regarding binutils at this
point. When Linux 2.6.32 is EOLed I expect to propose moving to 3.2 as
minimum Linux kernel version, allowing cleaning up lots of __ASSUME
conditionals. In general I think we should be happy to update these
versions based either on a certain amount of time since the release of the
other package, or based on what versions of the other package are still
supported by its maintainers, rather than needing a detailed debate each
time. Exceptions may apply if distributors were known to be very slow in
upgrading, e.g. some have been slow moving beyond make 3.81.)
> so as a general point, this isn't actually that useful. instead it would
> be written as:
> * Being able to assume __atomic_* are supported by the compiler for some arches
> and some builtins iff the builtin expands into insns
Given how tricky verifying the accuracy of code for concurrency and
atomics is, I think each architecture whose inline asm or __sync uses can
be replaced gets a significant benefit from moving to
architecture-independent atomics that only need verifying once.
> > The version increase would fix at least one known bug (17404, for mips16)
> > by removing the case where __sync_* are used but don't have sufficient
> > barriers (though for non-mips16 MIPS __atomic_* are best used only with
> > 4.8 and later).
> i'm not sure why that bug couldn't be fixed now for 4.7+ with a __GNUC_PREREQ
> check. that would make finding examples for dropping 4.6 support easier to
It is fixed for 4.7+. Being able to close open bugs is an incremental
improvement, and if a bug is only relevant for builds with old GCC, or
uses with an old Linux kernel, etc., increasing the minimum versions can
open the way to closing bugs.
Joseph S. Myers