Re: configure adds -std=gnu++11 to CXX variable

On Tue, 28 May 2024, Jakub Jelinek via Gcc wrote: > -std=gnu23 support is still incomplete even in GCC 14. It doesn't involve ABI issues, however, unlike C++, so using the option with GCC 14 is comparatively safe. (It might run into a few aliasing bugs related to tag compatibility right now,

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote: > These are also a trip hazard for novices, and the only way to turn them > off is with -std=cXX, which also turns another trip hazard (trigraphs) > *on*… so yeah, anything you can do to help speed up their removal, I > think it’d be worthwhile.

Re: On time64 and Large File Support

On Fri, 11 Nov 2022, Paul Eggert wrote: > One possible way forward would be for glibc to change its defaults for > _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. This See my notes at on what would be

Re: Future plans for Autotools

On Wed, 27 Jan 2021, Richard Purdie wrote: > Thanks, I hadn't realised. The only two recipes we never autoreconf are > binutils and gcc, instead we do some painful things to handle libtool > issues so we get our libtool tweaks. It sounds like we should revisit > that. I guess we were so used to

Re: Future plans for Autotools

On Tue, 26 Jan 2021, Richard Purdie wrote: > I've also not seen mention of it but the fact that GCC and the > toolchain use an ancient version of autoconf has always been rather sad > to me. I moved GCC from 2.64 to 2.69 in 2018 (building on Simon Marchi's implementation of the same move for

Re: [PATCH] AC_LANG_INT_SAVE: Modernize function declarators (C89 and above).

On Wed, 5 Aug 2020, Zack Weinberg wrote: > +1 from me regardless -- we should be phasing out the use of pre-ANSI > constructs in autoconf's generated C snippets, and this is as good a > place to start as any. Note that C2x no longer had old-style function definitions and treats () in a function

Re: Android and iOS triplets are not recognized

On Wed, 4 Mar 2020, Jeffrey Walton wrote: > Unfortunately, none of these are recognized: > > armv7a-android-linux > aarch64-android-linux > x86-android-linux > i686-android-linux > x86_64-android-linux > amd64-android-linux config.sub has canonicalized these since

Re: [PATCH] AC_USE_SYSTEM_EXTENSIONS: port to recent ISO C

On Wed, 14 Sep 2016, Paul Eggert wrote: > > (There are other feature test macros for > > ISO C extensions as well.) > > Thanks, is there a list of these new macros somewhere? I might as well add > them all now. ISO 24747 defines __STDC_WANT_MATH_SPEC_FUNCS__ (must be defined to expand to the

Re: [PATCH] AC_USE_SYSTEM_EXTENSIONS: port to recent ISO C

On Tue, 13 Sep 2016, Paul Eggert wrote: > * lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS): > Also define __STDC_WANT_IEC_60559_BFP_EXT__, > __STDC_WANT_IEC_60559_FUNCS_EXT__, and __STDC_WANT_LIB_EXT2__. Why not __STDC_WANT_IEC_60559_TYPES_EXT__ (which makes GCC 7's declare limits for