* C2x features status @ 2022-10-20 17:30 Joseph Myers 2022-10-21 18:31 ` Florian Weimer 0 siblings, 1 reply; 9+ messages in thread From: Joseph Myers @ 2022-10-20 17:30 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-20 17:30 C2x features status Joseph Myers @ 2022-10-21 18:31 ` Florian Weimer 2022-10-21 19:14 ` Marek Polacek 2022-10-21 21:11 ` Joseph Myers 0 siblings, 2 replies; 9+ messages in thread From: Florian Weimer @ 2022-10-21 18:31 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc * 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-21 18:31 ` Florian Weimer @ 2022-10-21 19:14 ` Marek Polacek 2022-10-21 19:29 ` Arsen Arsenović 2022-10-21 21:11 ` Joseph Myers 1 sibling, 1 reply; 9+ messages in thread From: Marek Polacek @ 2022-10-21 19:14 UTC (permalink / raw) To: Florian Weimer; +Cc: Joseph Myers, gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-21 19:14 ` Marek Polacek @ 2022-10-21 19:29 ` Arsen Arsenović 2022-10-21 19:55 ` Florian Weimer 0 siblings, 1 reply; 9+ messages in thread From: Arsen Arsenović @ 2022-10-21 19:29 UTC (permalink / raw) To: Florian Weimer, gcc-patches; +Cc: gcc, Joseph Myers, Marek Polacek [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-21 19:29 ` Arsen Arsenović @ 2022-10-21 19:55 ` Florian Weimer 2022-10-21 20:26 ` Arsen Arsenović 0 siblings, 1 reply; 9+ messages in thread From: Florian Weimer @ 2022-10-21 19:55 UTC (permalink / raw) To: Arsen Arsenović; +Cc: gcc-patches, gcc, Joseph Myers, Marek Polacek * 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-21 19:55 ` Florian Weimer @ 2022-10-21 20:26 ` Arsen Arsenović 0 siblings, 0 replies; 9+ messages in thread From: Arsen Arsenović @ 2022-10-21 20:26 UTC (permalink / raw) To: gcc-patches; +Cc: gcc-patches, gcc, Joseph Myers, Marek Polacek, Florian Weimer [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-21 18:31 ` Florian Weimer 2022-10-21 19:14 ` Marek Polacek @ 2022-10-21 21:11 ` Joseph Myers 2022-10-21 22:13 ` Florian Weimer 1 sibling, 1 reply; 9+ messages in thread From: Joseph Myers @ 2022-10-21 21:11 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-21 21:11 ` Joseph Myers @ 2022-10-21 22:13 ` Florian Weimer 2022-10-21 22:19 ` Joseph Myers 0 siblings, 1 reply; 9+ messages in thread From: Florian Weimer @ 2022-10-21 22:13 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc * 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C2x features status 2022-10-21 22:13 ` Florian Weimer @ 2022-10-21 22:19 ` Joseph Myers 0 siblings, 0 replies; 9+ messages in thread From: Joseph Myers @ 2022-10-21 22:19 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-10-21 22:19 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-20 17:30 C2x features status Joseph Myers 2022-10-21 18:31 ` Florian Weimer 2022-10-21 19:14 ` Marek Polacek 2022-10-21 19:29 ` Arsen Arsenović 2022-10-21 19:55 ` Florian Weimer 2022-10-21 20:26 ` Arsen Arsenović 2022-10-21 21:11 ` Joseph Myers 2022-10-21 22:13 ` Florian Weimer 2022-10-21 22:19 ` Joseph Myers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).