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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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, but hopefully we'll have fixes for 
those backported for 14.2 as wrong-code issues.  And of course code 
testing __STDC_VERSION__ with GCC 14 or before needs to handle 
incompleteness of the implementation.)  Once we have #embed implemented 
(and so are substantially feature-complete, modulo the optional standard 
function attributes [[unsequenced]] and [[reproducible]]) it should be 
reasonable to change the default to -std=gnu23 (though we'll need to see 
what the distribution build impact from such a change is, especially 
regarding bool, true and false becoming keywords).

This certainly doesn't guarantee there won't be future C features with ABI 
issues from using an unstable version, however (if some C2y draft adds a 
new feature, then it's implemented, then the specification changes in an 
ABI-incompatible way - for an old example, consider how early C9x drafts 
had an enum-based definition of _Bool, which changed later to a built-in 
type like in C++, thereby changing from the size of int to a single byte).  
Indeed the API for some library functions in TS 18661-1 changed for the 
versions in C23, but that can be handled in glibc through symbol 
versioning (done some time ago for the totalorder functions, not yet done 
for fromfp functions).

Joseph S. Myers

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux