This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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

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

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

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

conform/ tests could also use -std=c11 instead of the present -std=c1x 
-D_ISOC11_SOURCE.

glibc could also be built with -std=gnu11 and use max_align_t from 
stddef.h instead of needing our own local version of it as at present.

The CMPLX macros from <complex.h> could also be used in libm and tests 
when convenient instead of needing to assign to __real__ and __imag__.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]