On Wed, 11 Jun 2025, Marek Polacek wrote: > This patch adds the C23 Support in GCC table (compiler features only). > > While creating it, I've consulted Annex M.2, our own changes.html, > Joseph's "ISO C23 support in the GNU Toolchain" Cauldron presentation, > https://en.cppreference.com/w/c/compiler_support.html, > https://clang.llvm.org/c_status.html#c2x, as well as git archives.
What's the logic for the ordering? It doesn't appear to be the order in which things appear in M.2 (M.3 in C2y drafts), which makes it much harder to review for completeness (I think the starting point is that entries should correspond one-to-one with those in each subclause of Annex M, possibly split up where it's useful to report separately on parts of a feature, but not reordered - this applies to previous versions as well, but the C23 list is much longer than the C11 one). Maybe there are useful things to list that aren't included in the Annex M list, but having everything from the Annex M list is an appropriate starting point. (Library features are appropriate to keep in the lists. Eventually these lists should consistently cover status in the GNU toolchain, so with glibc versions as well, or both GCC and glibc versions for features with both compiler and library aspects.) > + <tr> > + <td>Binary integer constants</td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2549.pdf";>N2549</a></td> > + <td class="supported">Yes</td> > + <td></td> > + </tr> GCC 4.3, commit f7fd775f0203c580b35b179976c665db3e4d9e46. > + <tr> > + <td><code>#warning</code></td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2686.pdf";>N2686</a></td> > + <td class="supported">Yes</td> > + <td></td> > + </tr> GCC 2.0, it seems. > + <tr> > + <td><code>__has_include</code></td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2799.pdf";>N2799</a></td> > + <td class="supported">Yes</td> > + <td></td> > + </tr> GCC 5. > + <tr> > + <!-- r10-3658-g843f104d5bc6d1 --> > + <td><code>strftime</code> supports <code>%OB</code> and <code>%Ob</code> > + formats</td> > + <td></td> > + <td class="supported"><a href="../gcc-10/changes.html#c">10</a></td> > + <td>harmonization with ISO/IEC 9945; glibc support for these formats > + was added in glibc 2.27</td> GCC version would need a note here that it's about format checking, given that this feature is formally just a library feature. > + <tr> > + <!-- r11-4537 --> > + <td>Give <code>true</code> and <code>false</code> in > <code><stdbool.h></code> > + type <code>_Bool</code></td> > + <td></td> > + <td class="supported"><a href="../gcc-11/changes.html#c">11</a></td> > + <td></td> > + </tr> Where does this entry come from? It was an intermediate development before bool, true and false became keywords and stdbool.h became a legacy header; I don't see it in Annex M and it doesn't belong there either, because from the logical user perspective of changes between C17 and C23, this intermediate state is irrelevant. > + <tr> > + <!-- r11-4462-g75ce04fba49eb3 --> > + <td>Allow duplicate attributes</td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2557.pdf";>N2557</a></td> > + <td class="supported"><a href="../gcc-11/changes.html#c">11</a></td> > + <td></td> > + </tr> This also doesn't belong here as it relates to an intermediate state that didn't allow duplicate attributes. The logical feature of attributes (and those of particular supported attributes) has to be considered to include all subsequent changes to those features up to the release of C23. (This also illustrates why adding a C2y table now means you're making significant future maintenance work for yourself, because a claim "C2y feature X is supported in GCC version N" can be true now and *become untrue and require the table to be changed to reflect that* when the feature - the logical feature from the perspective of a future user - gets expanded before C2y is released, so it's no longer supported and the actual GCC version for the final feature is some later version.) > +<!-- Probably doesn't belong here. Added in r12-4362. > + <tr> > + <td>Format checking <code>%b</code>, <code>%B</code> formats</td> > + <td></td> > + <td class="supported"><a href="../gcc-12/changes.html#c">12</a></td> > + <td></td> > + </tr> > +--> Well, I'd say that the Annex M entry "binary integer literals and appropriate formatting for input/output of binary integer numbers" should be split into two. Binary integer literals is a compiler feature, listed as such. Formatted input/output should be remarked as mainly a glibc feature (printf support in glibc 2.35, scanf support in 2.38; PRIb*, PRIB* and SCNb* macros in inttypes.h also in 2.38) but also with GCC format checking support. And the integer literals have a secondary library part (strtol etc), also in glibc 2.38. > + <tr> > + <!-- r13-2324-g2eca4ff4e867eb --> > + <td><code>[[maybe_unused]]</code> for labels </td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2662.pdf";>N2662</a></td> > + <td class="supported"><a href="../gcc-13/changes.html#c">13</a></td> > + <td></td> > + </tr> Again, intermediate states of the working draft are not relevant to users. This is simply part of the maybe_unused attribute feature (so implying GCC 13 as an appropriate version to list there, possibly noting that support other than on labels was available earlier). > + <tr> > + <!-- r13-3360-g3b3083a598ca3f --> > + <!-- r13-3534-ge0997c14af5e8b --> > + <td>Enhanced Enumerations (fixed underlying types)</td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3029.htm";>N3029</a>, > + <a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3030.htm";>N3030</a></td> > + <td class="supported"><a href="../gcc-13/changes.html#c">13</a></td> > + <td></td> > + </tr> There should be a separate entry for "improved rules for handling enumerations without underlying types, in particular allowing for enumerations without fixed underlying type to have value representations that have a greater range than int", or have I missed the corresponding entry here? (That entry should list some long-ago version that first supported a feature, possibly with a note about some semantics being adjusted in GCC 13 (the first of the two commits you list) to match the C23 semantics - even though that adjustment broke the Linux kernel build, I don't think it's sufficient to consider the feature unsupported earlier. > + <tr> > + <!-- r13-4541-gce53cf7b61ea6b --> > + <td><code>__VA_OPT__</code></td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3033.htm";>N3033</a></td> > + <td class="supported"><a href="../gcc-13/changes.html#c">13</a></td> > + <td>first support added in <a href="../gcc-8/changes.html#c">GCC > 8</a></td> > + </tr> The convention for these tables is that the main version listed is when the feature was substantially supported - not the version in which there was some -pedantic adjustment to diagnostics with a given -std= version. > + <tr> > + <td>Bit-precise integer types (<code>_BitInt</code>)</td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf";>N2763</a>, > + <a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2775.pdf";>N2775</a>, > + <a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2969.htm";>N2969</a>, > + <a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3035.pdf";>N3035</a></td> > + <td class="supported"><a href="../gcc-14/changes.html#c">14</a></td> > + <td>IA-32, x86-64 and AArch64 (little-endian) only</td> > + </tr> This is going to need to keep being updated when more targets get support, to indicate the relevant versions for each target. It's probably also past time to chase up all the target maintainers individually who haven't added support yet (to ABIs and then to GCC). > + <tr> > + <td>IEEE 754 decimal floating-point types</td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2341.pdf";>N2341</a></td> > + <!-- XXX Correct? --> > + <td class="supported">Yes</td> > + <td></td> > + </tr> Supported only for x86_64/x86/powerpc/s390/aarch64 (AArch64 more recently than others, so there should maybe be per-target versions somewhere). Also worth noting explicitly that this is an optional feature, unlike _BitInt where targets without support aren't fully implementing C23. The version listed could reasonably be when DFP was first added to GCC rather than subsequent -pedantic etc. updates. > + <tr> > + <td>IEEE 754 interchange and extended types</td> > + <td><a > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2601.pdf";>N2601</a></td> > + <!-- XXX Correct? --> > + <td class="supported">Yes</td> > + <td>C23 follows TS 18661-3 (support added in <a > href="../gcc-7/changes.html#c">GCC 7</a>)</td> > + </tr> > +</table> GCC 7 for the main support for binary types. Support for the Annex H suffixes for DFP types was only added in commit 856809e582bacbceb70cdae56feb86da367f379e, and support for _Decimal64x in commit 1910ecf15bfcc560dc5089d42c9d75bc30b35c2a, so we didn't have the decimal FP side of this before then. This whole feature should also be noted as optional. -- Joseph S. Myers josmy...@redhat.com
