Status of C99 features in GCC

C99 is substantially completely supported as of GCC 4.5 (with -std=c99 -pedantic-errors used; -fextended-identifiers 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.

This table is based on the list in the foreword to N1256 (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)).

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 -std=c99 -pedantic-errors (for versions 3.0 and later), as well as -fextended-identifiers 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.

See below the table for further notes on some issues.

Feature Version Notes restricted character set support via digraphs and <iso646.h> (originally specified in AMD1) GCC 2.7 wide character library support in <wchar.h> and <wctype.h> (originally specified in AMD1) N/A Library feature, no compiler support required. GCC doesn't have wprintf , wscanf and wcsftime format checking support. more precise aliasing rules via effective type N/A Optimization, no compiler support required. GCC has optimized based on aliasing rules since GCC 2.95. restricted pointers GCC 2.95 variable length arrays GCC 0.9 Various corner cases fixed in GCC 4.5. flexible array members GCC 3.0 static and type qualifiers in parameter array declarators GCC 3.1 complex (and imaginary) support in <complex.h> GCC 3.0 New functions are a library issue not requiring much compiler support (some built-in functions present). Complex numbers are supported with __complex__ since GCC 2.5, and with C99 _Complex 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). type-generic math macros in <tgmath.h> N/A Library feature; GCC built-in functions may be used in implementing it. the long long int type and library functions ≤ GCC 1.27 New functions are a library issue not requiring much compiler support (some built-in functions present). increased minimum translation limits GCC 0.9 GNU policy has always avoided arbitrary limits. additional floating-point characteristics in <float.h> GCC 3.0 remove implicit int GCC 3.0 reliable integer division GCC 0.9 universal character names ( \u and \U ) GCC 3.1 extended identifiers GCC 4.1 Some corner cases were fixed in GCC 5; -fextended-identifiers was needed to enable this feature before that version. hexadecimal floating-point constants and %a and %A printf / scanf conversion specifiers GCC 2.8 Conversion specifiers are a library issue (format checking support present). compound literals GCC 3.1 The syntax was supported by GCC by version 1.21, but with significant differences from C99 requirements until GCC 3.1. designated initializers GCC 3.0 The syntax was supported since GCC 2.5, but with significant differences from C99 requirements until GCC 3.0. // comments GCC 2.7 extended integer types and library functions in <inttypes.h> and <stdint.h> N/A All of this can be provided by the library rather than the compiler (some built-in function support also present). <stdint.h> 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 char , GCC retains this definition although it is not permitted by C99. remove implicit function declaration GCC 3.0 preprocessor arithmetic done in intmax_t / uintmax_t GCC 3.3 mixed declarations and code GCC 3.0 new block scopes for selection and iteration statements GCC 3.0 integer constant type rules GCC 3.3 integer promotion rules GCC 4.0 macros with a variable number of arguments GCC 2.95 the vscanf family of functions in <stdio.h> and <wchar.h> N/A Library feature, no compiler support required (format checking support present). additional math library functions in <math.h> N/A Library feature, no compiler support required (various built-in functions present). treatment of error conditions by math library functions ( math_errhandling ) N/A Library feature, no compiler support required. floating-point environment access in <fenv.h> N/A Library feature, no compiler support required. IEC 60559 (also known as IEC 559 or IEEE arithmetic) support Optional feature, not properly supported in GCC. trailing comma allowed in enum declaration GCC 0.9 %lf conversion specifier allowed in printf N/A Library feature, no compiler support required (format checking support present). inline functions GCC 4.3 Inline function support present since at least GCC 1.21, but with major differences from C99 semantics until 4.3. the snprintf family of functions in <stdio.h> N/A Library feature, no compiler support required (format checking support present). boolean type in <stdbool.h> GCC 3.0 GCC 2.95 had <stdbool.h> , but based on an early draft with major differences from C99 semantics. idempotent type qualifiers GCC 3.0 Always has been allowed, with a warning as required by C90 depending on GCC version. empty macro arguments GCC 0.9 Undefined behavior in C90, but GCC not known ever to have handled them contrary to C99. new structure type compatibility rules (tag compatibility) GCC 0.9 This relates to compatibility between translation units. additional predefined macro names GCC 3.0 Support for the compiler to implicitly preinclude a file stdc-predef.h provided by the C library, and so predefine macros relating to library properties for the whole translation unit, is new in GCC 4.8. _Pragma preprocessing operator GCC 3.0 standard pragmas Not implemented. Associated command-line options to control the state of the pragmas for the whole translation unit are available. __func__ predefined identifier GCC 2.95 va_copy macro GCC 3.0 additional strftime conversion specifiers N/A Library feature, no compiler support required (format checking support present). LIA compatibility annex N/A This annex describes how C relates to another standard, and does not impose any requirements on C implementations. deprecate ungetc at the beginning of a binary file N/A Library feature, no compiler support required. remove deprecation of aliased array parameters GCC 0.9 GCC has never done anything regarding this deprecation. conversion of array to pointer not limited to lvalues GCC 3.1 Some support since GCC 2.0, but with major differences from C99 requirements before GCC 3.1. relaxed constraints on aggregate and union initialization ≤ GCC 1.21 relaxed restrictions on portable header names GCC 0.9 GCC has never had such restrictions itself. return without expression not permitted in function that returns a value (and vice versa) GCC 3.0

Further notes

cpp has limited support for multibyte character sets.

IEC 60559 is IEEE 754 floating point. This works if and only if the hardware is perfectly compliant, but GCC does not define __STDC_IEC_559__ or implement the associated standard pragmas; nor do some options such as -frounding-math to enable the pragmas globally work in all cases (for example, required exceptions may not be generated) and contracting expressions (e.g., using fused multiply-add) is not restricted to source-language expressions as required by C99.

or implement the associated standard pragmas; nor do some options such as to enable the pragmas globally work in all cases (for example, required exceptions may not be generated) and contracting expressions (e.g., using fused multiply-add) is not restricted to source-language expressions as required by C99. For thorough support of math_errhandling the compiler needs to mark its output from compilations using -fno-trapping-math or -fno-math-errno , possibly using the .gnu_attribute mechanism, to indicate that built-in function optimizations may have been applied that mean that not all calls report error status in a particular way; the static linker needs to put this information in executables and shared libraries and the C library needs to use it to set math_errhandling at startup to a conservatively correct value based on the information from the compiler. There is currently some limited GNU C Library support that only conforms as long as the above options are not used anywhere in the program.

the compiler needs to mark its output from compilations using or , possibly using the mechanism, to indicate that built-in function optimizations may have been applied that mean that not all calls report error status in a particular way; the static linker needs to put this information in executables and shared libraries and the C library needs to use it to set at startup to a conservatively correct value based on the information from the compiler. There is currently some limited GNU C Library support that only conforms as long as the above options are not used anywhere in the program. const -qualified compound literals could share storage with each other and with string literals, but currently don't.

-qualified compound literals could share storage with each other and with string literals, but currently don't. The information provided by static in parameter array declarators is not used for optimization. It might make sense to use it in future in conjunction with work on prefetching.