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] |
On 05 Nov 2014 21:08, Joseph Myers wrote: > On Wed, 5 Nov 2014, Mike Frysinger wrote: > > any time you use a gcc feature you must review to see if it's supported by the > > versions we support. bumping the min gcc version doesn't preclude that. if > > No (even if autoconf kept testing for ISO C90 features long after doing so > was unnecessary). You just need to be aware of what's recent and not care > about the versions in which longstanding features were introduced - and > expanding the set of features that count as longstanding reduces the load > of keeping track of what's recent (you only need to review if using a > feature that might be on the borderline, and otherwise can either use > features without thinking about compiler versions, or know that a feature > is only usable conditionally, either of which is much more efficient than > needing to check). i don't buy it. we aren't talking about "long standing features" here, nor has it really come up before. every request has been for a recentish feature. > > > I think -Werror makes it more likely building with old versions will break > > > when they aren't actively tested. We also now have a clear use for > > > diagnostic pragmas, new in 4.6, to allow more selective disabling of > > > particular warnings together with -Werror. > > > > -Werror makes sense when building from git / maintainer mode, but not in any > > other scenario (such as unpacking release tarballs and running plain configure). > > Defaulting to disabling -Werror for releases (or based on compiler > version) was previously objected to in > <https://sourceware.org/ml/libc-alpha/2012-08/msg00404.html>. as long as there is a --disable-werror flag, i don't care about the default. no release is every going to build warning free in all configurations. it isn't just a gcc version skew issue. > > so your argument hinges on whether the new atomic logic should require gcc 4.7. > > that should probably shake out in the relevant threads and once it has, you've > > got a compelling reason for dropping <4.7. but i still don't see any > > justification for, if we are retaining 4.6, why we should drop 4.4 & 4.5. > > It's already been stated - using #pragma GCC diagnostic push/pop to help > with -Werror usage. OK -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |