Re: C2x features status

[Florian Weimer <fweimer@redhat.com>]

* Joseph Myers:

> On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote:
>
>> Do you have a list of C2X features that are likely to impact autoconf
>> tests?  Or planned changes in the GCC 13 and 14 default language modes
>> that reject constructs previous accepted as an extension?
>
> I think by far the biggest risk - for builds of old code in general, not 
> necessarily for autoconf tests - comes from the following two changes / 
> groups of changes:
>
> * Change of () in function declarations and definitions to mean (void), as 
> in C++, instead of an unprototyped function.

Hmm, I might need some help to create an instrumented GCC for that.
Maybe keep the processing of declarations as-is, to tell () and (void)
apart, but error out if a function declared without a prototype is
called with one or more arguments?

(The instrumentation works by recording certain errors in ways that an
existing build system will not suppress.  At the end of the build, we
check that no such errors have occurred, otherwise the build is flagged
for manual analysis.  Curiously, it doesn't work that well for the
original project, implicit function declarations—of course there are
some functions we do not implement and whose configure tests are
expected to fail!  But it should give good results for errors which
really can't happen.)

> * New keywords formerly in the user namespace: alignas alignof bool 
> constexpr false nullptr static_assert thread_local true typeof 
> typeof_unqual.  (I haven't yet implemented C2x constexpr, but hope to get 
> to it for GCC 13.  The others are all keywords now in C2x mode on GCC 
> mainline.)  Of these, by far the greatest risk is probably from bool, 
> false and true,

Thanks, I can probably fake this into the GCC-12-based compiler somehow.

> while typeof was enabled by default for -std=gnu* anyway 
> in previous releases so is a lower risk.

Do the semantics of typeof change to align with C++, so that typeof
(int) becomes invalid?

> There are also many new library functions, which obviously pose a risk to 
> programs using those identifiers for their own purposes and also including 
> the relevant header.  I hope the risk from those is lower in general.  
> Many of those aren't yet implemented in glibc; I've been focusing on 
> compiler rather than library features during GCC development stage 1, and 
> also hoping to be able to wait for MPFR 4.2 to be released before 
> implementing many of the new <math.h> functions (to avoid 
> gen-auto-libm-tests depending on an unreleased MPFR version).

Historically, we haven't tracked breakage from changes like the new
iszero macro proactively.  I haven't seen silent autoconf test failures
due to <math.h> changes.  Maybe we can fix issues as they result in
build failures instead.

Thanks,
Florian