Re: RFC: requiring GCC >= 4.7 to build glibc

[Joseph Myers <joseph at codesourcery dot com>]

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

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
joseph@codesourcery.com