Re: compiler standards (and/or min gcc version) supported with installed headers ?

[Mike Frysinger <vapier at gentoo dot org>]

On Wednesday 02 January 2013 14:59:42 Joseph S. Myers wrote:
> On Wed, 2 Jan 2013, Mike Frysinger wrote:
> > On Wednesday 02 January 2013 10:17:46 Joseph S. Myers wrote:
> > > On Wed, 2 Jan 2013, Carlos O'Donell wrote:
> > > > I say we agree that 2.95.3 is the oldest compiler we will support
> > > > for compiling userspace applications using glibc headers.
> > > 
> > > Given that the headers are generally meant to support non-GCC
> > > compilers, I think all you might gain is elimination of cases
> > > specifically for older GCC, so that older GCC uses the same cases as
> > > non-GCC.  Simply changing __GNUC_PREREQ (2, 95) to __GNUC__ is hardly
> > > a gain.  (And where the older-GCC case is simply an optimization, or
> > > where the older-GCC and non-GCC cases have similar functionality
> > > that's not fully conforming, I think a more recent baseline such as
> > > 4.1 would be reasonable.)
> > 
> > i don't think 4.1 is reasonable.  i def see people actively using gcc-3.3
> > and gcc-3.4 today (when things break, i get reports fairly quickly).
> 
> But how important is it that users of 3.3 get the macro definition of
> __mempcpy (that's used for __GNUC_PREREQ (3, 0) && !__GNUC_PREREQ (3, 4)),
> rather than just getting calls to the out-of-line __mempcpy in glibc (like
> non-GCC compilers), for example?  That's the issue involved where the
> version conditionals are just about optimizations: removing complicated
> macro definitions that won't actually have been tested with the glibc
> testsuite for several years.

if you're specifically talking about optimization, then i don't have a problem 
with dropping that.  i thought you were talking more generally.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.