C2x features status

C2x features status

[Joseph Myers]

I'm working on adding various C2x features to the C front end (and 
elsewhere in GCC as applicable).

I suspect I won't get all the C2x features done for GCC 13.  If anyone 
else is interested in adding C2x features, I'd encourage looking at some 
of the following, which I may well not get to for GCC 13 (and posting here 
to avoid duplication of effort if working on such a feature):

* Bit-precise integer types (_BitInt) (see bug 102989) (integrated version 
based on N2763, plus literal suffixes from N2775 and bit-fields from 
N2969).  Would require working with back-end maintainers and upstream ABI 
groups, where available, to get ABIs defined for as many architectures as 
possible, as well as some default ABI choice in GCC for architectures that 
haven't defined the ABI for these types.

* [[unsequenced]] and [[reproducible]] attributes for function types.  See 
N2956.  These are supposed to be similar to const and pure attributes, at 
least in the absence of pointer and array function parameters (but note 
they never affect type compatibility).

* Tag compatibility (N3037, alternative wording).  Martin Uecker might 
have patches for a draft version of this?

* Preprocessor #embed (N3017) (see bug 105863).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C2x features status

[Florian Weimer]

* Joseph Myers:

> I'm working on adding various C2x features to the C front end (and 
> elsewhere in GCC as applicable).
>
> I suspect I won't get all the C2x features done for GCC 13.  If anyone 
> else is interested in adding C2x features, I'd encourage looking at some 
> of the following, which I may well not get to for GCC 13 (and posting here 
> to avoid duplication of effort if working on such a feature):
>
> * Bit-precise integer types (_BitInt) (see bug 102989) (integrated version 
> based on N2763, plus literal suffixes from N2775 and bit-fields from 
> N2969).  Would require working with back-end maintainers and upstream ABI 
> groups, where available, to get ABIs defined for as many architectures as 
> possible, as well as some default ABI choice in GCC for architectures that 
> haven't defined the ABI for these types.
>
> * [[unsequenced]] and [[reproducible]] attributes for function types.  See 
> N2956.  These are supposed to be similar to const and pure attributes, at 
> least in the absence of pointer and array function parameters (but note 
> they never affect type compatibility).
>
> * Tag compatibility (N3037, alternative wording).  Martin Uecker might 
> have patches for a draft version of this?
>
> * Preprocessor #embed (N3017) (see bug 105863).

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'm asking because I'm working on the implicit function declaration
problem once more, and other things could be piggybacked on the tool
support over time.  See the parallel “C89isms in the test suite” thread.

I wonder if anything went into the default C2X language mode already
that could be similarly disruptive as the removal of implicit ints?  In
that case, I should probably backport that change into my GCC test
version.  (To avoid chasing ghosts, it's based off GCC 12, I've decided
to decouple it from our planned switch to GCC 13.)

Thanks,
Florian

Re: C2x features status

[Marek Polacek]

On Fri, Oct 21, 2022 at 08:31:09PM +0200, Florian Weimer via Gcc wrote:
> * Joseph Myers:
> 
> > I'm working on adding various C2x features to the C front end (and 
> > elsewhere in GCC as applicable).
> >
> > I suspect I won't get all the C2x features done for GCC 13.  If anyone 
> > else is interested in adding C2x features, I'd encourage looking at some 
> > of the following, which I may well not get to for GCC 13 (and posting here 
> > to avoid duplication of effort if working on such a feature):
> >
> > * Bit-precise integer types (_BitInt) (see bug 102989) (integrated version 
> > based on N2763, plus literal suffixes from N2775 and bit-fields from 
> > N2969).  Would require working with back-end maintainers and upstream ABI 
> > groups, where available, to get ABIs defined for as many architectures as 
> > possible, as well as some default ABI choice in GCC for architectures that 
> > haven't defined the ABI for these types.
> >
> > * [[unsequenced]] and [[reproducible]] attributes for function types.  See 
> > N2956.  These are supposed to be similar to const and pure attributes, at 
> > least in the absence of pointer and array function parameters (but note 
> > they never affect type compatibility).
> >
> > * Tag compatibility (N3037, alternative wording).  Martin Uecker might 
> > have patches for a draft version of this?
> >
> > * Preprocessor #embed (N3017) (see bug 105863).
> 
> 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?

At least this one:

commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Wed Sep 7 13:56:25 2022 +0000

    c: New C2x keywords

which says:

    As with the removal of unprototyped functions, this change has a high
    risk of breaking some old code and people doing GNU/Linux distribution
    builds may wish to see how much is broken in a build with a -std=gnu2x
    default.
 
> I'm asking because I'm working on the implicit function declaration
> problem once more, and other things could be piggybacked on the tool
> support over time.  See the parallel “C89isms in the test suite” thread.
> 
> I wonder if anything went into the default C2X language mode already
> that could be similarly disruptive as the removal of implicit ints?  In
> that case, I should probably backport that change into my GCC test
> version.  (To avoid chasing ghosts, it's based off GCC 12, I've decided
> to decouple it from our planned switch to GCC 13.)
> 
> Thanks,
> Florian
> 

Marek

Re: C2x features status

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote:
> commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca
> Author: Joseph Myers <joseph@codesourcery.com>
> Date:   Wed Sep 7 13:56:25 2022 +0000
> 
>     c: New C2x keywords
> 
> which says:
> 
>     As with the removal of unprototyped functions, this change has a
> high risk of breaking some old code and people doing GNU/Linux
> distribution builds may wish to see how much is broken in a build
> with a -std=gnu2x default.

It already does break a lot.  See https://bugs.gentoo.org/870412 
(comments go over the details).  I was intending on giving this issue a 
proper look in the GNU toolchain frame of reference, but never got 
around to it (and I kinda knocked priority down after managing to 
configure properly once IIRC).

-- 
Arsen Arsenović

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: C2x features status

[Florian Weimer]

* Arsen Arsenović:

> On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote:
>> commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca
>> Author: Joseph Myers <joseph@codesourcery.com>
>> Date:   Wed Sep 7 13:56:25 2022 +0000
>> 
>>     c: New C2x keywords
>> 
>> which says:
>> 
>>     As with the removal of unprototyped functions, this change has a
>> high risk of breaking some old code and people doing GNU/Linux
>> distribution builds may wish to see how much is broken in a build
>> with a -std=gnu2x default.
>
> It already does break a lot.  See https://bugs.gentoo.org/870412 
> (comments go over the details).  I was intending on giving this issue a 
> proper look in the GNU toolchain frame of reference, but never got 
> around to it (and I kinda knocked priority down after managing to 
> configure properly once IIRC).

That's the implicit function declaration/implicit int change.  This
won't happen in GCC 13, it's too late for that.  I tried to make this
change a couple of years in Fedora, and just flipping the compiler flag
Does Not Work.  I hope to get there in time for GCC 14.

Thank you for sharing the Gentoo tracker.  Maybe we can reuse some
patches from there and contribute ours.  I trust Gentoo aims to upstream
patches as they become available?  Unfortunately, I expect that a lot of
these issues will be in packages that don't have an active upstream
anymore, which makes sharing patches more challenging.  In other cases,
we'll just build with -std=gnu89 (e.g. unzip
<https://bugzilla.redhat.com/show_bug.cgi?id=1750694>, it has
configure-style checking implemented without autoconf).

Thanks,
Florian

Re: C2x features status

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

On Friday, 21 October 2022 21:55:53 CEST Florian Weimer wrote:
> That's the implicit function declaration/implicit int change.  This
> won't happen in GCC 13, it's too late for that.  I tried to make this
> change a couple of years in Fedora, and just flipping the compiler
> flag Does Not Work.  I hope to get there in time for GCC 14.
The tracker also covers what clang calls strict-prototype (which is 
AFAICT about K&R style prototypes and () arg lists), so I figured it's 
relevant (but, IIRC, Clang is holding off on making that an error for 
now, so it was lower priority).

> Thank you for sharing the Gentoo tracker.  Maybe we can reuse some
> patches from there and contribute ours.  I trust Gentoo aims to
> upstream patches as they become available?  Unfortunately, I expect
> that a lot of these issues will be in packages that don't have an
> active upstream anymore, which makes sharing patches more
> challenging.  In other cases, we'll just build with -std=gnu89 (e.g.
> unzip
> <https://bugzilla.redhat.com/show_bug.cgi?id=1750694>, it has
> configure-style checking implemented without autoconf).
Yes, indeed, the devs that fixed packages did send patches usptream 
while they worked on this issue.  Unfortunately, there is dead 
upstreams, as you said, so I expect either lingering in-tree patches for 
issues or compile flag changes like the one for unzip you mentioned.  
Such contribution and collaboration is more than welcome, though; please 
do reach out.

Thanks,
-- 
Arsen Arsenović

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: C2x features status

[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.

* 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, while typeof was enabled by default for -std=gnu* anyway 
in previous releases so is a lower risk.

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).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C2x features status

[Florian Weimer]

* 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

Re: C2x features status

[Joseph Myers]

On Fri, 21 Oct 2022, Florian Weimer wrote:

> > 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?

No.  Both typeof (expr) and typeof (type) are valid.

The changes to make typeof (expr) consistently avoid returning a qualified 
or atomic type when passed an rvalue argument (while preserving qualifiers 
on lvalues) mostly went into previous releases, but I found and fixed a 
few more cases when implementing standard typeof (and all those fixes are 
unconditional).

typeof in C2x mode does not treat const or noreturn function attributes as 
part of the type of a function or function pointer, unlike typeof in 
previous modes and __typeof even in C2x mode.

-- 
Joseph S. Myers
joseph@codesourcery.com