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

[Mike Frysinger <vapier at gentoo dot org>]

On 20 Aug 2015 16:36, Joseph Myers wrote:
> On Thu, 20 Aug 2015, Mike Frysinger wrote:
> > On 20 Aug 2015 13:51, Joseph Myers wrote:
> > > For glibc 2.21 we increased the minimum GCC version for building glibc to 
> > > 4.6.  There's one major GCC release a year, so the correspondingly old 
> > > version for glibc 2.23 would be GCC 4.7.  What do people think about 
> > > increasing the minimum version requirement?
> > 
> > i'd like to see the diff (not exact, but at least get an idea).
> 
> 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.

> > > * Being able to assume __atomic_* are supported by the compiler if 
> > > desired.
> > 
> > do we actually get that ?  not all arches expand these as insns but
> > to external calls to libatomic.  unless we're ok with libc/libpthread
> > linking against libatomic ?
> 
> We get that for architectures where it's expanded inline, if we wish to 
> use it on those architectures (maybe through architectures choosing to 
> include a generic file after defining some macros to configure it).

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

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

> > > * When using pragmas to disable -Wmaybe-uninitialized warnings, no need to 
> > > have conditionals to disable -Wuninitialized instead for 4.6 
> > > (-Wmaybe-uninitialized was added in 4.7).
> > 
> > we could use -Wno-error for gcc-4.6 too ...
> 
> We're trying to move away from global -Wno- options....

yes, but as we've already seen & agreed upon, trying to support warning-free 
builds is not an exact science, and is generally best effort.  if we can replace 
a lot of sprinkled pragmas/macros in the source with a global -W flag for older 
versions, that sounds like a fine trade off to me.

> > > * More C11 support, so we no longer need to XFAIL some conform/ tests and 
> > > could use the new features in glibc if desired.
> > 
> > shouldn't we already be handling this and not XFAIL-ing when the compiler
> > is new enough ?
> 
> Although such configure tests would be possible, they'd seem like 
> overkill.

i'm not suggesting feature tests.  we're already testing & have access to the
compiler version which means it should be possible to leverage that data.
-mike

Attachment: signature.asc
Description: Digital signature