Re: C2x features status

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