On Wed, 16 Oct 2024, Jakub Jelinek via Gcc wrote:
> The cppreference page mentions as unimplemented on the GCC side
> N2653 - Type change of u8 string literals
commit 703837b2cc8ac03c53ac7cc0fb1327055acaebd2
Author: Tom Honermann <t...@honermann.net>
Date: Tue Aug 2 14:36:01 2022 -0400
C: Implement C2X N2653 char8_t and UTF-8 string literal changes
> and as only partially implemented
> N2341 - IEEE 754 decimal floating-point types
Various -pedantic and fixes done to reflect these being standard e.g.
commit 04a9b8d2f38573d0527edeea9e4fd9b7dfdc7983
Author: Joseph Myers <jos...@codesourcery.com>
Date: Thu Oct 14 20:56:29 2021 +0000
c-family: Support DFP printf/scanf formats for C2X
commit f8e4c55cbc09fbbe136b2ba2da405d7bdced07ae
Author: Joseph Myers <jos...@codesourcery.com>
Date: Tue Nov 17 00:27:06 2020 +0000
float.h: C2x decimal signaling NaN macros
commit 175a85b29718141d73230ed19efcfcf963a0d0b6
Author: Joseph Myers <jos...@codesourcery.com>
Date: Fri Oct 11 23:22:52 2019 +0100
Support decimal floating-point constants in C2x.
commit fe2bc27cdb6d572da0163d77e787ba644b400753
Author: Joseph Myers <jos...@codesourcery.com>
Date: Fri Oct 11 18:32:48 2019 +0100
Support _Decimal* keywords for C2x.
> N2601 - IEEE 754 interchange and extended types
C23 follows TS 18661-3 (support added in GCC 7). There was a late
-pedantic fix:
commit 80acabb6dd05090db67805cdd358fe974b45e2ed
Author: Jakub Jelinek <ja...@redhat.com>
Date: Wed Sep 6 08:51:00 2023 +0200
c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X
But as a general principle, I think we should consider and externally
document a feature as done in some GCC version if all the main pieces of
that feature are available to users - rather than only declaring it to be
done when every known corner case is fixed and all the -pedantic
diagnostics are right. That's the principle followed for the version
numbers listed in c99status.html for C99 features.
We *don't* support the DFP parts of Annex H / TS 18661-3 (_Decimal64x
type, dN / DN / dNx / DNx literal suffixes, etc.).
> N2900 - Empty initializers
GCC 13, like many C23 features.
commit 14cfa01755a66afbae2539f8b5796c960ddcecc6
Author: Joseph Myers <jos...@codesourcery.com>
Date: Thu Aug 25 21:02:57 2022 +0000
c: Support C2x empty initializer braces
> N2934 - New spelling of keywords
commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca
Author: Joseph Myers <jos...@codesourcery.com>
Date: Wed Sep 7 13:56:25 2022 +0000
c: New C2x keywords
> N3033 - __VA_OPT__
Implemented some time ago, and WG14 made sure to follow the same semantics
as C++. The -pedantic fix was
commit ce53cf7b61ea6bce05570e2fd1f8c10eee308ab0
Author: Joseph Myers <jos...@codesourcery.com>
Date: Wed Dec 7 19:18:06 2022 +0000
preprocessor: Enable __VA_OPT__ for C2x
We do still need to update the documentation of implementation-defined
behavior for C23, but that can't be done until C23 is actually published
and we know the final subclause numbers (there were many subclause
numbering changes since the last public working draft). Other
C23-relevant things such as making __int128 fully an integer type (bug
113887, involves both compiler and library pieces) are properly optional.
_BitInt support isn't optional (at least up to 64 bits), target
architecture maintainers need to be chased up about adding support to
their ABIs and back ends to get it done across more architectures.
Regarding the question of how we should document the status of support for
standard features in GCC:
Marek posted a patch
<https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595539.html> trying to
describe things by reference to WG14 paper numbers. My overall objection
<https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595540.html> was that
the list should be in a *user-oriented* arrangement rather than one
oriented to the minutiae of how changes were added to the standard over a
series of papers: it should list the actual features at the level of a
language user, as in c99status.html, and describe what is implemented in
terms of those features. See also the rest of that thread. The following
is based on what I wrote off-list to Marek in February (but updated) -
note I think user-oriented information covering glibc together with GCC
makes sense rather than just ignoring library features:
Take the lists of logical features for C11 and C23 from Annex M in latest
working draft. Right now that's N3301. Warning, that C2Y draft includes
changes that *weren't* approved relating to imaginary literals as a git
branch was wrongly merged with a mixture of approved and unapproved
changes (a substantially different version was accepted in Minneapolis).
So don't rely on it as reflecting the actual pre-Minneapolis C2Y accepted
content, but for changes in older standard versions it's a reasonable
source. (In the private C standard git repository Annex M now has a more
complete list of accepted changes in C2Y pre-Minneapolis, with many other
mistakes in integration of those papers fixed - though there are several
other pre-Minneapolis issues with merge requests to fix them awaiting
review.)
I think a new version of this might best be done as a patch series, to aid
review.
(a) Rename c99status.html, with appropriate redirects (including updating
existing redirects that point to c99status.html, and updating the manual
anywhere it points there).
(b) Check c99status.html against the list in Annex M.5 in C23 / M.6 in C2Y
(hopefully the list of features agrees).
(c) Also add library status in glibc for C99 features involving anything
in the library (possibly together with language pieces).
(d) Add C11 status - following the list in Annex M.
https://gcc.gnu.org/wiki/C11Status may provide helpful information about
versions, but it should be checked. If that page lists anything that
doesn't match entries on Annex M, then consider separately how to list
that information.
(e) Add C23 status (language and library), with appropriate notes in more
complicated cases (where different pieces of support were added at
different times etc.), like in the existing C99 list.
(f) Add anything you feel worth listing for C23 that's not in the Annex M
list (I tried in DIS ballot comments to identify anything missing I
thought was significant enough to be worth including as a user-visible
feature, but you might have different views in some cases of what should
count).
Adding information about the papers with specific feature proposals could
be done at any point along the way.
My talk from the 2023 Cauldron may help as a guide to C23 feature status
as of September 2023, though maybe not with specific version numbers in
all cases.
https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=ISO+C23+support+in+the+GNU+Toolchain.pdf
I have a list of various corner cases (from ballot comment resolutions at
various stages) I should try to get to for GCC 15, but I don't consider
that sort of corner case to be something that belongs on this list - "the
first GCC version in which support for the relevant feature was
substantially present" (and likewise for glibc versions), as in
c99status.html, seems to me to be the right thing to list, with additional
notes being included where relevant in more complicated cases.
--
Joseph S. Myers
josmy...@redhat.com
