[wwwdocs] Add C status page
Commit Message
I thought it'd be nice to have a table that documents our C support
status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++.
We have https://gcc.gnu.org/c99status.html, but that's C99 only.
So here's a patch to add just that. For C99, I used c99status.html but
added paper numbers (taken from https://clang.llvm.org/c_status.html).
I've filed the availability status of some of the features, but not all;
I know next to nothing about the floating-point features. I hope these
will get filed in due time.
It would also be nice to have a C DR table, like we have for C++:
https://gcc.gnu.org/projects/cxx-dr-status.html
but that's a bigger task.
Validated. Any comments before I push it?
Comments
On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
> I thought it'd be nice to have a table that documents our C support
> status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++.
> We have https://gcc.gnu.org/c99status.html, but that's C99 only.
>
> So here's a patch to add just that. For C99, I used c99status.html but
> added paper numbers (taken from https://clang.llvm.org/c_status.html).
For C11, see https://gcc.gnu.org/wiki/C11Status (note: I haven't checked
the accuracy of that page).
Listing in terms of features is more useful than listing in terms of
papers. Referring to the original paper, even if it's the version that
got accepted into the standard, is liable to be actively misleading to
anyone working on the implementation; sometimes the paper has multiple
choices of which only one was accepted into the standard, or only some of
the listed changes were accepted, or there were various subsequent
features or fixes from various subsequent papers. (By way of example, it
would make more sense to list _BitInt as a single entry for a missing
feature than to separately list N2763 and N2775 (accepted papers), while
N2960, to be considered at the July meeting of WG14, makes further wording
fixes but can't exactly be considered a feature in a sense that should be
listed in such a table.) Lots of papers are just cleanups, or
clarification of wording, or fixes to issues with previous papers, such
that it doesn't make sense to list them as implemented or not at all.
As usual there are also cases where a feature is implemented to the extent
relevant for conformance but e.g. more optimizations (such as built-in
functions) could be added. And cases where some support in GCC should
definitely be done to consider the feature implemented, even when not
needed for conformance (e.g. the %wN, %wfN printf/scanf formats need
implementing in glibc, and corresponding format checking support needs
implementing in GCC). There are also cases where a feature is
substantially there but a more detailed review should be done for how it
matches up to the standard version (e.g. the DFP support based on TR
24732-2009 could do with such a detailed review for how it matches C2x
requirements).
> + <tr>
> + <td>Binary literals</td>
> + <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2549.pdf">N2549</a></td>
> + <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
> + <td></td>
> + </tr>
This is an example of cases where the version where a feature was
supported in GCC as an extension is long before the version where
-pedantic knows about it being supported in a given standard version;
listing the version with the -pedantic change in such cases may not be
very helpful without noting when it was originally implemented. There are
probably other examples in the list. (There are also examples where GCC
supports the feature but hasn't yet had -pedantic updated accordingly,
e.g. #warning. And cases where it's largely supported but there are small
differences in the standard version that still need implementing, e.g.
typeof.)
> + <tr>
> + <td>What we think we reserve</td>
> + <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2572.pdf">N2572</a></td>
> + <td class="unsupported">?</td>
> + <td></td>
> + </tr>
This is an example of the many cases where it doesn't make sense to
consider something as a feature with an "implemented" or "not implemented"
state at all - so it doesn't belong in such a table at all. There are
many other such examples in the list.
On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
> + <!-- Nov 2020 Papers -->
This actually looks like a mix of papers approved at the Oct 2020 meeting
and those approved at the Nov/Dec 2020 meeting, though I haven't checked
the lists in detail against those the minutes show as being approved as-is
or with specified changes (as opposed to support "along the lines" = bring
back a revised paper for more discussion = doesn't belong in this list
unless it was actually approved into C2x at a subsequent meeting).
> + <!-- Apr 2021 Papers -->
There was a Mar 2021 meeting, not an Apr 2021 one.
There were also June 2021, Aug/Sep 2021, Nov 2021, Jan/Feb 2022 and May
2022 meetings, which don't appear in this list.
Also note that www.open-std.org now uses https so all links should be
updated accordingly.
The following are lists of papers accepted at the last two WG14 meetings,
sorted by whether, at the time of the meeting, I thought they needed
implementation work in GCC *or glibc*. Note that needing implementation
work, for the purposes of these lists, sometimes only means "needs a
review of existing code before I'm sure it *doesn't* need implementation
work", or "already implemented, but may need test cases added to the
testsuite", or "already implemented but -pedantic handling needs adjusting
accordingly" (sometimes the entries have notes I made to that effect) - it
does *not* necessarily mean a missing feature. Also note that some
entries on these lists may actually be part of a feature added at a
previous meeting for C2x that don't really deserve their own table entry,
and some may have been implemented since I took these notes at the
meetings. The descriptions of the papers in these lists are very
abbreviated, intended only for my own reference; they aren't the full
official paper titles or suitable for a list on the GCC website. And just
as I didn't distinguish language and library features (some papers have
both, of course), I also didn't distinguish *why* a paper doesn't need
implementation work (most often because it's not making any normative
changes of intent relevant to GCC or glibc, but sometimes maybe already
implemented or for other reasons).
Jan/Feb 2022, needed implementation work:
N2833 timegm (option 1, mktime->timegm typo fixed in Returns)
N2836 identifier syntax
[check any impact on $ in identifiers?] [check pp-number handling]
N2764 noreturn attribute
N2775 _BitInt literal suffixes
N2927 typeof
N2841 no function declarators without prototypes
(subject to editorial fixes, Aaron Ballman reflector 21595, 13 Feb 2022)
[note: revert previous changes to () compat with prototypes]
N2840 call_once, once_flag, ONCE_FLAG_INIT in stdlib.h
N2826 unreachable, macro in stddef.h (changes 5, 6) [no vote on change 7]
N2819 storage class of compound literals in function parameters
(adopting GCC behavior, but add tests including that non-const inits OK)
N2653 char8_t (Tom Honerman has GCC, glibc patches)
N2829 assert variadic macro
N2900 {} init (includes VLA initializers; -pedantic fixes to allow {})
(not including the Optional Change 0 on largest members)
N2828 Unicode Sequences More Than 21 Bits are a Constraint Violation
(diagnosed by GCC since Sep 2019, but check for tests before saying done)
N2931 tgmath narrowing (may need work along with other tgmath changes)
N2934 keywords alignas alignof bool static_assert thread_local
N2935 keywords / predefined constants true false
Jan/Feb 2022, no implementation work needed:
N2810 calloc wraparound (possibly remove "of", editorially)
N2797 *_HAS_SUBNORM (green text only)
N2754 DFP quantum exponent of NaN etc. ("would be" -> "is" in footnote)
N2844 (remove _FloatN default argument promotion)
N2847 "numerically equal" example change
N2879 5.2.4.2.2 cleanup
N2880 overflow and underflow definitions
N2881 normal and subnormal
("Larger magnitude ..." sentence is only new part not already in C23)
N2882 max exponent
N2762 potentially reserved identifiers
(remove "All library functions have external linkage." footnote)
N2701 @ and $ and ` (all three changes, need to be single-byte)
N2937 (blocks in grammar)
May 2022, needed implementation work:
N2867 checked n-bit integers (i.e. not required to support them)
N2886 remove ATOMIC_VAR_INIT (variant 2 + changes 3.2/3.3/3.4/3.5, not 3.6)
N2888 require exact-width integer type interfaces (3.1 already accepted)
(i.e., allowing exact-width types wider than (u)intmax_t)
No implementation work needed for conformance, BUT would allow
int128_t / uint128_t typedefs etc. given some other implementation changes
N2897 memset_explicit (Alternative 1)
May 2022, no implementation work needed:
N2861 indeterminate values and trap representations
(subject to editorial merges with other papers)
N2992 wording change for variably-modified types
For the previous three meetings, I have a more abbreviated version of such
lists.
Jun 2021, needed implementation work:
N2683 checked integer operations (core proposal only)
N2709 _BitInt (alternative 1) (minor wording changes) - also need
ABI proposals from authors
N2662 maybe_unused attribute for labels + __has_c_attribute value
change to 202106L [and make sure all std attr tests in GCC verify
whether can use on labels]
Jun 2021, no implementation work needed:
N2650 signbit, N2651 fabs/copysign changes 3+4, N2670 zeros compare equal,
N2671 negative, N2672 5.2.4.2.2 cleanup, N2665 zero-size realloc
Aug/Sep 2021, needed implementation work:
N2686 #warning
N2711 fmin/fmax removed from _FloatN etc. functions (consequent
tgmath.h changes needed in glibc as well)
N2799 __has_include (tests/pedantic, at least)
N2801 sized dealloc (wording candidate 2)
Aug/Sep 2021, no implementation work needed:
N2688 non-encodable proposed wording 1, N2710 NaN editorial + LDL -> LDBL,
N2713 int const expr, N2714 hypot + "returns a NaN", N2715 cr_*
reservation + keep "potentially", N2716 "numerically" changes 1, 3, N2745
range error - without footnote, N2748 fenv exceptions changes 2, 3, N2749
IEC 60559 binding, N2755 DFP init (with typo fix), N2726 I quals, N2728
char16,32_t
Nov 2021, needed implementation work:
N2848 INFINITY (Suggested change not Alternate, float.h, and also math.h)
Nov 2021, no implementation work needed:
N2781 compatible type with "." -> ";", N2778 VM types (with editorial
fixes?), N2770 UB function parameters, N2806 change to 5.2.4.2.2p4 [rest
already voted in, N2672] [affects normalized definition, may need more
changes to clarify for double-double], N2805 overflow/underflow [may need
more changes for double-double], N2747 Annex F underflow/overflow, N2842
normal/subnormal classification [may need more changes for double-double],
N2843 *_MAX_EXP [may need more changes for double-double], N2790 remquo,
N2823 strtodN (alternative 2 7.22.1.6#7 change only, expect Annex N
changes to follow separately - also note question of math_errhandling &
MATH_ERRNO being zero, can errno be set?), N2845 feraiseexcept update,
N2846 expression transformations maybe with "non-required features" ->
"extensions or optional features" or similar fixed editorially, N2808
ptrdiff_t first proposal, N2838 types and sizes Change 3.1 only, N2872
exact width types Change 3.1 only, N2837 integer terms
On Tue, May 24, 2022 at 06:11:09PM +0000, Joseph Myers wrote:
> On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
>
> > I thought it'd be nice to have a table that documents our C support
> > status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++.
> > We have https://gcc.gnu.org/c99status.html, but that's C99 only.
> >
> > So here's a patch to add just that. For C99, I used c99status.html but
> > added paper numbers (taken from https://clang.llvm.org/c_status.html).
>
> For C11, see https://gcc.gnu.org/wiki/C11Status (note: I haven't checked
> the accuracy of that page).
Ah, nice (I almost never use our wiki). One more reason to have a single
place for such overviews.
> Listing in terms of features is more useful than listing in terms of
> papers. Referring to the original paper, even if it's the version that
> got accepted into the standard, is liable to be actively misleading to
> anyone working on the implementation; sometimes the paper has multiple
> choices of which only one was accepted into the standard, or only some of
> the listed changes were accepted, or there were various subsequent
> features or fixes from various subsequent papers.
Right, so I think it would make sense to have one line for a feature, and
add related papers to the second column, as we do in the C++ table:
https://gcc.gnu.org/projects/cxx-status.html (see e.g. concepts).
> (By way of example, it
> would make more sense to list _BitInt as a single entry for a missing
> feature than to separately list N2763 and N2775 (accepted papers), while
> N2960, to be considered at the July meeting of WG14, makes further wording
> fixes but can't exactly be considered a feature in a sense that should be
> listed in such a table.)
OK, so I think we should have one feature ("_BitInt") and have those three
papers in the "Proposal" column.
> Lots of papers are just cleanups, or
> clarification of wording, or fixes to issues with previous papers, such
> that it doesn't make sense to list them as implemented or not at all.
For those either we could say "N/A" (gray color), or not mention them at
all, though I'd perfer the former.
> As usual there are also cases where a feature is implemented to the extent
> relevant for conformance but e.g. more optimizations (such as built-in
> functions) could be added.
Notes like these could go to the "Notes" column.
> And cases where some support in GCC should
> definitely be done to consider the feature implemented, even when not
> needed for conformance (e.g. the %wN, %wfN printf/scanf formats need
> implementing in glibc, and corresponding format checking support needs
> implementing in GCC).
These could be marked as "partially implemented" (yellow color). Except
I often don't know which features need extensions like that.
> There are also cases where a feature is
> substantially there but a more detailed review should be done for how it
> matches up to the standard version (e.g. the DFP support based on TR
> 24732-2009 could do with such a detailed review for how it matches C2x
> requirements).
Indeed, and that's a hard problem. I for one could never figure out this
one. So I'd leave it in the "?" (red color) state.
> > + <tr>
> > + <td>Binary literals</td>
> > + <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2549.pdf">N2549</a></td>
> > + <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
> > + <td></td>
> > + </tr>
>
> This is an example of cases where the version where a feature was
> supported in GCC as an extension is long before the version where
> -pedantic knows about it being supported in a given standard version;
> listing the version with the -pedantic change in such cases may not be
> very helpful without noting when it was originally implemented.
Probably here we could just say "Yes" (green color) and make a note in the
"Notes" column.
> There are
> probably other examples in the list. (There are also examples where GCC
> supports the feature but hasn't yet had -pedantic updated accordingly,
> e.g. #warning. And cases where it's largely supported but there are small
> differences in the standard version that still need implementing, e.g.
> typeof.)
Yeah, I bet. It's tricky to decide :/.
> > + <tr>
> > + <td>What we think we reserve</td>
> > + <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2572.pdf">N2572</a></td>
> > + <td class="unsupported">?</td>
> > + <td></td>
> > + </tr>
>
> This is an example of the many cases where it doesn't make sense to
> consider something as a feature with an "implemented" or "not implemented"
> state at all - so it doesn't belong in such a table at all. There are
> many other such examples in the list.
Maybe it's just me, but I find some value in having proposals like that in
the table too (but it should be "N/A" and gray). This is what I did for
N2641.
What I like about having a table like this is that it makes it clear what
remains to be implemented, and unimplemented features have a linked PR,
which makes it easy to see if someone is already planning to implement the
feature, or if it still unassigned.
Please let me know if you (dis)agree and I can give this another shot
(using your notes you provided in the other email).
Thanks,
Marek
On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote:
> > And cases where some support in GCC should
> > definitely be done to consider the feature implemented, even when not
> > needed for conformance (e.g. the %wN, %wfN printf/scanf formats need
> > implementing in glibc, and corresponding format checking support needs
> > implementing in GCC).
>
> These could be marked as "partially implemented" (yellow color). Except
> I often don't know which features need extensions like that.
I think something like how c99status.html lists wide character library
support is appropriate for the Notes (so along the lines of "Library
feature, no compiler support required. GCC doesn't have %wN, %wfN format
checking support.").
> > There are also cases where a feature is
> > substantially there but a more detailed review should be done for how it
> > matches up to the standard version (e.g. the DFP support based on TR
> > 24732-2009 could do with such a detailed review for how it matches C2x
> > requirements).
>
> Indeed, and that's a hard problem. I for one could never figure out this
> one. So I'd leave it in the "?" (red color) state.
I think the approach taken in c99status.html - list the version where
there is substantial support so code written with the new syntax will
generally work - is appropriate as regards the choice of version number to
list. So that would list GCC 4.3 as the version with DFP support (i.e.
the entry for TS 18661-2 integration - I don't think listing all the TS
18661 parts in a single row is right). And then it might be marked as
partially implemented. And the Notes would say (in some order) that (a)
support based on TR 24732-2009 may not have been fully updated to C2X
requirements, (b) both language and library features are involved, and
library support is in libdfp (link to libdfp) but might not be complete,
(c) there are issues with correct rounding of conversions between binary
and decimal DFP in some cases (link to bugs 97635, 105669), and issues
with exceptions and rounding modes similar to those that apply with binary
floating point, (d) DFP is only supported for a few architectures.
(I don't think the versions in which I made -std=c2x -pedantic allow DFP
features need to be mentioned at all.)
> > > + <tr>
> > > + <td>Binary literals</td>
> > > + <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2549.pdf">N2549</a></td>
> > > + <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
> > > + <td></td>
> > > + </tr>
> >
> > This is an example of cases where the version where a feature was
> > supported in GCC as an extension is long before the version where
> > -pedantic knows about it being supported in a given standard version;
> > listing the version with the -pedantic change in such cases may not be
> > very helpful without noting when it was originally implemented.
>
> Probably here we could just say "Yes" (green color) and make a note in the
> "Notes" column.
Following the same principle as c99status.html for chosing versions to
list says that the version number should be listed as GCC 4.3.
> > There are
> > probably other examples in the list. (There are also examples where GCC
> > supports the feature but hasn't yet had -pedantic updated accordingly,
> > e.g. #warning. And cases where it's largely supported but there are small
> > differences in the standard version that still need implementing, e.g.
> > typeof.)
>
> Yeah, I bet. It's tricky to decide :/.
(In the case of typeof, "partially implemented" is probably right anyway,
simply because of the remove_quals variant in C2x (for which there is a
proposal of renaming to be considered in July). And then note that typeof
itself, with some semantic differences, but not remove_quals, was
implemented in GCC 1.21 or before - similar to how c99status.html handles
complex numbers, noting that __complex__ was supported in GCC 2.5 but
_Complex not until GCC 3.0 which is the version listed in the version
column there.)
> Maybe it's just me, but I find some value in having proposals like that in
> the table too (but it should be "N/A" and gray). This is what I did for
> N2641.
>
> What I like about having a table like this is that it makes it clear what
> remains to be implemented, and unimplemented features have a linked PR,
> which makes it easy to see if someone is already planning to implement the
> feature, or if it still unassigned.
I don't object to having non-features listed as N/A, but I think you'll
have a lot of rows like that. Library features (that don't need compiler
support) should be explicitly noted as such when marking them as N/A.
I have rough notes on C2x features needing implementing in GCC and glibc
(sorted approximately by the relevant commits in the (private) C standard
git repository), but that isn't a straightforward checklist intended to be
more widely comprehensible or to map to corresponding PRs, includes cases
of possible future improvements not actually needed to consider a feature
implemented, and doesn't distinguish whether something needs implementing
in GCC, glibc or both.
new file mode 100644
@@ -0,0 +1,995 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>C Standards Support in GCC</title>
+<link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css" />
+</head>
+
+<body>
+ <h1>C Standards Support in GCC</h1>
+
+ GCC supports different dialects of C, corresponding to the multiple
+ published ISO standards. Which standard it implements can be selected using
+ the <code>-std=</code> command-line option.
+
+ <ul>
+ <li><a href="#c89">C89</a></li>
+ <li><a href="#c99">C99</a></li>
+ <li><a href="#c11">C11</a></li>
+ <li><a href="#c17">C17</a></li>
+ <li><a href="#c2x">C2x</a></li>
+ </ul>
+
+<!-- We don't have this yet, but we should.
+ <p>For information about the status of C defect reports, please see
+ <a href="https://gcc.gnu.org/projects/c-dr-status.html">this page</a>.
+ </p>
+-->
+
+ <h2 id="c2x">C2x Support in GCC</h2>
+
+ <p>GCC has experimental support for the next revision of the C
+ standard.</p>
+
+ <p>C2X features are available since GCC 9. To enable C2X support, add the
+ command-line parameter <code>-std=c2x</code> to your <code>gcc</code> command
+ line. Or, to enable GNU extensions in addition to C2X features, add
+ <code>-std=gnu2x</code>. These options are available since
+ <a href="../gcc-9/changes.html">GCC 9</a>.</p>
+
+ <p><strong>Important</strong>: Because the ISO C2X standard is still
+ evolving, GCC's support is <strong>experimental</strong>. No attempt will
+ be made to maintain backward compatibility with implementations of C2X
+ features that do not reflect the final standard.</p>
+
+ <h2>C2X Language Features</h2>
+
+ <table class="cxxstatus">
+ <tr class="separator">
+ <th>Language Feature</th>
+ <th>Proposal</th>
+ <th>Available in GCC?</th>
+ <th>Notes</th>
+ </tr>
+ <!-- Pre-Oct 2019 Papers -->
+ <tr>
+ <td>Evaluation formats</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2186.pdf">N2186</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Clarifying the restrict Keyword v2</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf">N2660</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Harmonizing static_assert with C++</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2265.pdf">N2665</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>nodiscard attribute</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2667.pdf">N2667</a></td>
+ <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>maybe_unused attribute</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2670.pdf">N2670</a></td>
+ <td class="supported"><a href="../gcc-10/changes.html">GCC 10</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>TS 18661 Integration</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2314.pdf">N2314</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2341.pdf">N2341</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2401.pdf">N2401</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2359.pdf">N2359</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2546.pdf">N2546</a></td>
+ <td class="unsupported">?</td>
+ <td>This is supported at least partially.</td>
+ </tr>
+ <tr>
+ <td>Preprocessor line numbers unspecified</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2322.htm">N2322</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>deprecated attribute</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2334.pdf">N2334</a></td>
+ <td class="supported"><a href="../gcc-10/changes.html">GCC 10</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Attributes</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2335.pdf">N2335</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2554.pdf">N2554</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Defining new types in offsetof</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm">N2350</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>fallthrough attribute</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2408.pdf">N2408</a></td>
+ <td class="supported"><a href="../gcc-10/changes.html">GCC 10</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Two's complement sign representation</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf">N2412</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Adding the u8 character prefix</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2418.pdf">N2418</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Remove support for function definitions with identifier lists</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf">N2432</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <!-- Oct 2019 Papers -->
+ <tr>
+ <td>*_IS_IEC_60559 feature test macros</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2379.htm">N2379</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Floating-point negation and conversion</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2416.pdf">N2416</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Annex F.8 update for implementation extensions and rounding</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2384.pdf">N2384</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>_Bool definitions for true and false</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2393.pdf">N2393</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <!-- Mar 2020 Papers -->
+ <tr>
+ <td>[[nodiscard("should have a reason")]]</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2448.pdf">N2448</a></td>
+ <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Allowing unnamed parameters in function definitions</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2480.pdf">N2480</a></td>
+ <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
+ <td></td>
+ </tr>
+ <!-- Aug 2020 Papers -->
+ <tr>
+ <td>Free positioning of labels inside compound statements</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2508.pdf">N2508</a></td>
+ <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Clarification request for C17 example of undefined behavior</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2517.pdf">N2517</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Querying attribute support</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2553.pdf">N2553</a></td>
+ <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
+ <td></td>
+ </tr>
+ <!-- Nov 2020 Papers -->
+ <tr>
+ <td>Binary literals</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2549.pdf">N2549</a></td>
+ <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Allow duplicate attributes</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2557.pdf">N2557</a></td>
+ <td class="supported"><a href="../gcc-11/changes.html">GCC 11</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Character encoding of diagnostic text</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2563.pdf">N2563</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>What we think we reserve</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2572.pdf">N2572</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Decimal floating-point triples</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2580.htm">N2580</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Remove mixed wide string literal concatenation</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2594.htm">N2594</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Update to IEC 60559:2020</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2600.pdf">N2600</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Compatibility of Pointers to Arrays with Qualifiers</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2607.pdf">N2607</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <!-- Apr 2021 Papers -->
+ <tr>
+ <td>String functions for freestanding implementations</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2524.htm">N2524</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Digit separators</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2626.pdf">N2626</a></td>
+ <td class="supported"><a href="../gcc-12/changes.html">GCC 12</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Missing DEC_EVAL_METHOD</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2640.htm">N2640</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Missing +(x) in table</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2641.htm">N2641</a></td>
+ <td class="other">N/A</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Add support for preprocessing directives elifdef and elifndef</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2645.pdf">N2645</a></td>
+ <td class="supported"><a href="../gcc-12/changes.html">GCC 12</a></td>
+ <td></td>
+ </tr>
+ </table>
+
+ <h2 id="c17">C17 Support in GCC</h2>
+
+ <p>C17 was published in July 2018. There are no major changes in this edition,
+ only technical corrections and clarifications. This mode is the default since
+ GCC 11 (<a href="https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c76dc9c3">git</a>);
+ it can be explicitly selected with the <code>-std=c17</code> command-line
+ flag, or <code>-std=gnu17</code> to enable GNU extensions as well.</p>
+
+ <h2 id="c11">C11 Support in GCC</h2>
+
+ <p>This mode can be selected with the <code>-std=c11</code> command-line flag,
+ or <code>-std=gnu11</code> to enable GNU extensions as well (available since
+ <a href="../gcc-4.7/changes.html">GCC 4.7</a>).</p>
+
+ <table class="cxxstatus">
+ <tr class="separator">
+ <th>Language Feature</th>
+ <th>Proposal</th>
+ <th>Available in GCC?</th>
+ <th>Notes</th>
+ </tr>
+ <tr>
+ <td>A finer-grained specification for sequencing</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1252.htm">N1252</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Clarification of expressions</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1282.pdf">N1282</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Extending the lifetime of temporary objects (factored approach)</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1285.htm">N1285</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Requiring signed char to have no padding bits</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm">N1310</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Initializing static or external variables</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1311.pdf">N1311</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Conversion between pointers and floating types</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1316.htm">N1316</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Adding TR 19769 to the C Standard Library</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1326.pdf">N1326</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Static assertions</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1330.pdf">N1330</a></td>
+ <td class="supported"><a href="../gcc-4.6/changes.html">GCC 4.6</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Parallel memory sequencing model proposal</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm">N1349</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Analyzability (#1, #4 - conditionally normative)</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1350.htm">N1350</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>FLT_EVAL_METHOD issues (first change only)</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1353.pdf">N1353</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>_Bool bit-fields</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1356.htm">N1356</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Technical corrigendum for C1X</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1359.htm">N1359</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Benign typedef redefinition</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1360.htm">N1360</a></td>
+ <td class="supported"><a href="../gcc-4.6/changes.html">GCC 4.6</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Thread-local storage</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1364.htm">N1364</a></td>
+ <td class="supported"><a href="../gcc-4.9/changes.html">GCC 4.9</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Constant expressions</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1365.htm">N1365</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Contractions and expression evaluation methods</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1367.htm">N1367</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>FLT_EVAL_METHOD and return</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1382.htm">N1382</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Floating-point to int/_Bool conversions</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1391.htm">N1391</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Analyzability (along the lines)</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1394.htm">N1394</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Wide function returns (alternate proposal)</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1396.htm">N1396</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Alignment</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1397.htm">N1397</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1447.htm">N1447</a></td>
+ <td class="supported"><a href="../gcc-4.7/changes.html">GCC 4.7</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Anonymous member-structures and unions (modulo "name lookup")</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1406.pdf">N1406</a></td>
+ <td class="supported"><a href="../gcc-4.6/changes.html">GCC 4.6</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Completeness of types</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1439.pdf">N1439</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Generic macro facility</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1441.htm">N1441</a></td>
+ <td class="supported"><a href="../gcc-4.9/changes.html">GCC 4.9</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Dependency ordering for C memory model</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1444.htm">N1444</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Subsetting the standard</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1460.htm">N1460</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Assumed types in F.9.2</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1468.htm">N1468</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Supporting the 'noreturn' property in C1x</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1478.htm">N1478</a></td>
+ <td class="supported"><a href="../gcc-4.7/changes.html">GCC 4.7</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Updates to C++ memory model based on formalization</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1480.htm">N1480</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Explicit initializers for atomics</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1482.htm">N1482</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Atomics proposal (minus ternary op)</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1485.pdf">N1485</a></td>
+ <td class="supported"><a href="../gcc-4.9/changes.html">GCC 4.9</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>UTF-8 string literals</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1488.htm">N1488</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Optimizing away infinite loops</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1509.pdf">N1509</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Conditional normative status for Annex G</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1514.pdf">N1514</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Creation of complex value</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1464.htm">N1464</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Recommendations for extended identifier characters for C and C++</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1518.htm">N1518</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Atomic C1x/C++0x compatibility refinements (1st part only)</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1526.pdf">N1526</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Small fix for the effect of alignment on struct/union type compatibility</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1532.htm">N1532</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Synthesis re _Atomic</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1537.htm">N1537</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Clarification for wide evaluation</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1531.pdf">N1531</a></td>
+ <td class="unsupported">?</td>
+ <td></td>
+ </tr>
+ </table>
+
+ <h2 id="c99">C99 Support in GCC</h2>
+
+ <p>C99 is substantially completely supported as of GCC 4.5
+ (with <code>-std=c99 -pedantic-errors</code> used;
+ <code>-fextended-identifiers</code> also needed to enable extended
+ identifiers before GCC 5), modulo bugs and floating-point
+ issues (mainly but not entirely relating to optional C99 features from
+ Annexes F and G). The following table gives more details of the C99
+ support in different GCC versions.</p>
+
+ <p>This table is based on the list in the foreword to <a
+ href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf">N1256</a>
+ (ISO/IEC 9899:1999 (E), consolidated with ISO/IEC 9899:1999/Cor.1:2001
+ (E), ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007
+ (E)).</p>
+
+ <p>The "Version" column indicates the first GCC version in which
+ support for the relevant feature was substantially present; some bugs
+ or corner cases may have been fixed in later versions; this column is
+ "N/A" if nothing is needed from the compiler for the feature to be
+ substantially supported (for example, if the feature refers to
+ addition of new library functions rather than language features), even
+ if additional compiler features could be useful in conjunction with
+ it. It is assumed that GCC is used with <code>-std=c99
+ -pedantic-errors</code> (for versions 3.0 and later), as well
+ as <code>-fextended-identifiers</code> in the case of that feature
+ before GCC 5.
+ Where library cooperation is required, it is assumed that a recent
+ version of the GNU C Library is in use, and support with other C
+ libraries may be less good. Where the version listed is before GCC
+ 3.0, it should not be assumed that all corner cases follow C99 before
+ GCC 3.0, even if there is no specific note regarding corner cases.</p>
+
+ <p>See below the table for further notes on some issues.</p>
+
+ <p>This mode can be selected with the <code>-std=c99</code> command-line
+ flag, or <code>-std=gnu99</code> to enable GNU extensions as well.</p>
+ <p>Not all C99 documents are publicly available, so the documents
+ referenced in this section may be missing.</p>
+
+ <table class="cxxstatus">
+ <tr class="separator">
+ <th>Language Feature</th>
+ <th>Proposal</th>
+ <th>Available in GCC?</th>
+ <th>Notes</th>
+ </tr>
+ <tr>
+ <td>restricted character set support via digraphs and
+ <code><iso646.h></code> (originally specified in AMD1)</td>
+ <td></td>
+ <td class="supported">GCC 2.7</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>wide character library support in <code><wchar.h></code> and
+ <code><wctype.h></code> (originally specified in AMD1)</td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required. GCC doesn't have
+ <code>wprintf</code>, <code>wscanf</code> and <code>wcsftime</code>
+ format checking support.</td>
+ </tr>
+ <tr>
+ <td>more precise aliasing rules via effective type</td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Optimization, no compiler support required. GCC has optimized based
+ on aliasing rules since GCC 2.95.</td>
+ </tr>
+ <tr>
+ <td>restricted pointers</td>
+ <td>N448</td>
+ <td class="supported">GCC 2.95</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>variable length arrays</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n683.htm">N683</a></td>
+ <td class="supported">GCC 0.9</td>
+ <td>Various corner cases fixed in GCC 4.5.</td>
+ </tr>
+ <tr>
+ <td>flexible array members</td>
+ <td></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>static</code> and type qualifiers in parameter array
+ declarators</td>
+ <td></td>
+ <td class="supported"><a href="../gcc-3.1/changes.html">GCC 3.1</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>complex (and imaginary) support in <code><complex.h></code></td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n620.ps">N620</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n638.ps">N638</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n657.ps">N657</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n694.ps">N694</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n809.ps">N809</a>
+ </td>
+ <td class="supported">GCC 3.0</td>
+ <td>New functions are a library issue not requiring much compiler
+ support (some built-in functions present). Complex numbers are
+ supported with <code>__complex__</code> since GCC 2.5, and with
+ C99 <code>_Complex</code> since GCC 3.0. Complex multiplication
+ and division support C99 special cases since GCC 4.0. Various
+ corner cases were fixed in GCC 4.5. GCC does not support the
+ Annex G imaginary types, but this support is optional, and complex
+ multiplication and division have excess overflows at runtime
+ (although not beyond those permitted by C99).</td>
+ </tr>
+ <tr>
+ <td>type-generic math macros in <code><tgmath.h></code></td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n693.ps">N693</a></td>
+ <td class="supported">N/A</td>
+ <td>Library feature; GCC built-in functions may be used in implementing
+ it.</td>
+ </tr>
+ <tr>
+ <td>the <code>long long int</code> type and library functions</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n601.ps">N601</a></td>
+ <td class="supported">GCC 1.27</td>
+ <td>New functions are a library issue not requiring much compiler
+ support (some built-in functions present).</td>
+ </tr>
+ <tr>
+ <td>increased minimum translation limits</td>
+ <td>N590</td>
+ <td class="supported">GCC 0.9</td>
+ <td>GNU policy has always avoided arbitrary limits.</td>
+ </tr>
+ <tr>
+ <td>additional floating-point characteristics in <code><float.h></code></td>
+ <td></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>remove implicit <code>int</code></td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n635.htm">N635</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n692.htm">N692</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n722.htm">N722</a>
+ </td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>reliable integer division</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n617.htm">N617</a></td>
+ <td class="supported">GCC 0.9</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>universal character names (<code>\u</code> and <code>\U</code>)</td>
+ <td></td>
+ <td class="supported"><a href="../gcc-3.1/changes.html">GCC 3.1</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>extended identifiers</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n717.htm">N717</a></td>
+ <td class="supported"><a href="../gcc-4.1/changes.html">GCC 4.1</a></td>
+ <td>Some corner cases were fixed in GCC 5; <code>-fextended-identifiers</code>
+ was needed to enable this feature before that version.</td>
+ </tr>
+ <tr>
+ <td>hexadecimal floating-point constants and <code>%a</code> and
+ <code>%A</code> <code>printf</code>/<code>scanf</code> conversion
+ specifiers</td>
+ <td>N308</td>
+ <td class="supported">GCC 2.8</td>
+ <td>Conversion specifiers are a library issue (format checking support
+ present).</td>
+ </tr>
+ <tr>
+ <td>compound literals</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n716.htm">N716</a></td>
+ <td class="supported"><a href="../gcc-3.1/changes.html">GCC 3.1</a></td>
+ <td>The syntax was supported by GCC by version 1.21, but with significant
+ differences from C99 requirements until GCC 3.1.</td>
+ </tr>
+ <tr>
+ <td>designated initializers</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n494.pdf">N494</a></td>
+ <td class="supported">GCC 3.0</td>
+ <td>The syntax was supported since GCC 2.5, but with significant
+ differences from C99 requirements until GCC 3.0.</td>
+ </tr>
+ <tr>
+ <td><code>//</code> comments</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n644.htm">N644</a></td>
+ <td class="supported">GCC 2.7</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>extended integer types and library functions in
+ <code><inttypes.h></code> and <code><stdint.h></code></td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>All of this can be provided by the library rather than the
+ compiler (some built-in function support also
+ present). <code><stdint.h></code> is provided by GCC (as of
+ version 4.5), or fixed where the system headers provide a
+ nonconforming version, on some but not yet all systems. On
+ systems where types in this header have been defined
+ as <code>char</code>, GCC retains this definition although it is
+ not permitted by C99.</td>
+ </tr>
+ <tr>
+ <td>remove implicit function declaration</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n636.htm">N636</a></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>preprocessor arithmetic done in <code>intmax_t</code>/<code>uintmax_t</code></td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n736.htm">N736</a></td>
+ <td class="supported"><a href="../gcc-3.3/changes.html">GCC 3.3</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>mixed declarations and code</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n740.htm">N740</a></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>new block scopes for selection and iteration statements</td>
+ <td></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>integer constant type rules</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n629.htm">N629</a></td>
+ <td class="supported"><a href="../gcc-3.3/changes.html">GCC 3.3</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>integer promotion rules</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n725.htm">N725</a></td>
+ <td class="supported"><a href="../gcc-4.0/changes.html">GCC 4.0</a></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>macros with a variable number of arguments</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n707.htm">N707</a></td>
+ <td class="supported">GCC 2.95</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>the <code>vscanf</code> family of functions in
+ <code><stdio.h></code> and <code><wchar.h></code></td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required (format checking
+ support present).</td>
+ </tr>
+ <tr>
+ <td>additional math library functions in <code><math.h></code></td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required (various built-in
+ functions present).</td>
+ </tr>
+ <tr>
+ <td>treatment of error conditions by math library functions
+ (<code>math_errhandling</code>)</td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required.</td>
+ </tr>
+ <tr>
+ <td>floating-point environment access in <code><fenv.h></code></td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required.</td>
+ </tr>
+ <tr>
+ <td>IEC 60559 (also known as IEC 559 or IEEE arithmetic) support</td>
+ <td></td>
+ <td></td>
+ <td>Optional feature, not properly supported in GCC.</td>
+ </tr>
+ <tr>
+ <td>trailing comma allowed in <code>enum</code> declaration</td>
+ <td></td>
+ <td class="supported">GCC 0.9</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>%lf</code> conversion specifier allowed in <code>printf</code></td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required (format checking
+ support present).</td>
+ </tr>
+ <tr>
+ <td>inline functions</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n741.htm">N741</a></td>
+ <td class="supported"><a href="../gcc-4.0/changes.html">GCC 4.0</a></td>
+ <td>Inline function support present since at least GCC 1.21, but
+ with major differences from C99 semantics until 4.3.</td>
+ </tr>
+ <tr>
+ <td>the <code>snprintf</code> family of functions in <code><stdio.h></code></td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required (format checking
+ support present).</td>
+ </tr>
+ <tr>
+ <td>boolean type in <code><stdbool.h></code></td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n815.htm">N815</a></td>
+ <td class="supported">GCC 3.0</td>
+ <td>GCC 2.95 had <code><stdbool.h></code>, but based on an
+ early draft with major differences from C99 semantics.</td>
+ </tr>
+ <tr>
+ <td>idempotent type qualifiers</td>
+ <td>N505</td>
+ <td class="supported">GCC 3.0</td>
+ <td>Always has been allowed, with a warning as required by C90
+ depending on GCC version.</td>
+ </tr>
+ <tr>
+ <td>empty macro arguments</td>
+ <td>N570</td>
+ <td class="supported">GCC 0.9</td>
+ <td>Undefined behavior in C90, but GCC not known ever to have
+ handled them contrary to C99.</td>
+ </tr>
+ <tr>
+ <td>new structure type compatibility rules (tag compatibility)</td>
+ <td>N522</td>
+ <td class="supported">GCC 0.9</td>
+ <td>This relates to compatibility between translation units.</td>
+ </tr>
+ <tr>
+ <td>additional predefined macro names</td>
+ <td></td>
+ <td class="supported">GCC 3.0</td>
+ <td>Support for the compiler to implicitly preinclude a file
+ <code>stdc-predef.h</code> provided by the C library, and so
+ predefine macros relating to library properties for the whole
+ translation unit, is new in GCC 4.8.</td>
+ </tr>
+ <tr>
+ <td><code>_Pragma</code> preprocessing operator</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n634.ps">N634</a></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>standard pragmas</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n631.htm">N631</a><br>
+ <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n696.ps">N696</a></td>
+ <td class="unsupported">No</td>
+ <td>Not implemented. Associated command-line options to control
+ the state of the pragmas for the whole translation unit are
+ available.</td>
+ </tr>
+ <tr>
+ <td><code>__func__</code> predefined identifier</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n611.ps">N611</a></td>
+ <td class="supported">GCC 2.95</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>va_copy</code> macro</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n671.htm">N671</a></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>additional <code>strftime</code> conversion specifiers</td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required (format checking
+ support present).</td>
+ </tr>
+ <tr>
+ <td>LIA compatibility annex</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n792.htm">N792</a></td>
+ <td class="other">N/A</td>
+ <td>This annex describes how C relates to another standard, and
+ does not impose any requirements on C implementations.</td>
+ </tr>
+ <tr>
+ <td>deprecate <code>ungetc</code> at the beginning of a binary file</td>
+ <td></td>
+ <td class="supported">N/A</td>
+ <td>Library feature, no compiler support required.</td>
+ </tr>
+ <tr>
+ <td>remove deprecation of aliased array parameters</td>
+ <td></td>
+ <td class="supported">GCC 0.9</td>
+ <td>GCC has never done anything regarding this deprecation.</td>
+ </tr>
+ <tr>
+ <td>conversion of array to pointer not limited to lvalues</td>
+ <td></td>
+ <td class="supported"><a href="../gcc-3.1/changes.html">GCC 3.1</a></td>
+ <td>Some support since GCC 2.0, but with major differences from
+ C99 requirements before GCC 3.1.</td>
+ </tr>
+ <tr>
+ <td>relaxed constraints on aggregate and union initialization</td>
+ <td></td>
+ <td class="supported">GCC 1.21</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>relaxed restrictions on portable header names</td>
+ <td><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n772.htm">N772</a></td>
+ <td class="supported">GCC 0.9</td>
+ <td>GCC has never had such restrictions itself.</td>
+ </tr>
+ <tr>
+ <td><code>return</code> without expression not permitted in function
+ that returns a value (and vice versa)</td>
+ <td></td>
+ <td class="supported">GCC 3.0</td>
+ <td></td>
+ </tr>
+ </table>
+
+ <h2 id="c89">C89 Support in GCC</h2>
+
+ GCC has full support for the 9899:1990 C standard as modified by the 1995
+ technical corrigendum and some later defect reports.
+
+ <p>This mode is the default in GCC versions prior to 5.1; it can be
+ explicitly selected with the <code>-std=c89</code> command-line flag,
+ or <code>-std=gnu89</code> to enable GNU extensions as well.</p>
+
+</body>
+</html>