[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A conforming implementation of ISO C is required to document its choice of behavior in each of the areas that are designated "implementation defined". The following lists all such areas, along with the section numbers from the ISO/IEC 9899:1990 and ISO/IEC 9899:1999 standards. Some areas are only implementation-defined in one version of the standard.
Some choices depend on the externally determined ABI for the platform (including standard character encodings) which GCC follows; these are listed as "determined by ABI" below. See section Binary Compatibility, and http://gcc.gnu.org/readings.html. Some choices are documented in the preprocessor manual. See section `Implementation-defined behavior' in The C Preprocessor. Some choices are made by the library and operating system (or other environment when compiling for a freestanding environment); refer to their documentation for details.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Diagnostics consist of all the output sent to stderr by GCC.
See section `Implementation-defined behavior' in The C Preprocessor.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The behavior of most of these points are dependent on the implementation of the C library, and are not defined by GCC itself.
See section `Implementation-defined behavior' in The C Preprocessor.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
See section `Implementation-defined behavior' in The C Preprocessor.
For internal names, all characters are significant. For external names, the number of significant characters are defined by the linker; for almost all targets, all characters are significant.
This is a property of the linker. C99 requires that case distinctions are always significant in identifiers with external linkage and systems without this property are not supported by GCC.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Determined by ABI.
Determined by ABI.
Determined by ABI.
char
object into which has been stored any
character other than a member of the basic execution character set
(C90 6.1.2.5, C99 6.2.5).
Determined by ABI.
signed char
or unsigned char
has the same
range, representation, and behavior as "plain" char
(C90
6.1.2.5, C90 6.2.1.1, C99 6.2.5, C99 6.3.1.1).
Determined by ABI. The options `-funsigned-char' and `-fsigned-char' change the default. See section Options Controlling C Dialect.
Determined by ABI.
See section `Implementation-defined behavior' in The C Preprocessor.
See section `Implementation-defined behavior' in The C Preprocessor.
See section `Implementation-defined behavior' in The C Preprocessor.
See section `Implementation-defined behavior' in The C Preprocessor.
See section `Implementation-defined behavior' in The C Preprocessor.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GCC does not support any extended integer types.
GCC supports only two's complement integer types, and all bit patterns are ordinary values.
GCC does not support any extended integer types.
For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised.
Bitwise operators act on the representation of the value including both the sign and value bits, where the sign bit is considered immediately above the highest-value value bit. Signed `>>' acts on negative numbers by sign extension.
GCC does not use the latitude given in C99 only to treat certain aspects of signed `<<' as undefined, but this is subject to change.
GCC always follows the C99 requirement that the result of division is truncated towards zero.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
<math.h>
and <complex.h>
that return floating-point
results (C90 and C99 5.2.4.2.2).
The accuracy is unknown.
FLT_ROUNDS
(C90 and C99 5.2.4.2.2).
GCC does not use such values.
FLT_EVAL_METHOD
(C99 5.2.4.2.2).
GCC does not use such values.
C99 Annex F is followed.
C99 Annex F is followed.
C99 Annex F is followed.
FP_CONTRACT
pragma (C99 6.5).
Expressions are currently only contracted if `-funsafe-math-optimizations' or `-ffast-math' are used. This is subject to change.
FENV_ACCESS
pragma (C99 7.6.1).
This pragma is not implemented, but the default is to "off" unless `-frounding-math' is used in which case it is "on".
This is dependent on the implementation of the C library, and is not defined by GCC itself.
FP_CONTRACT
pragma (C99 7.12.2).
This pragma is not implemented. Expressions are currently only contracted if `-funsafe-math-optimizations' or `-ffast-math' are used. This is subject to change.
This is dependent on the implementation of the C library, and is not defined by GCC itself.
This is dependent on the implementation of the C library, and is not defined by GCC itself.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A cast from pointer to integer discards most-significant bits if the pointer representation is larger than the integer type, sign-extends(2) if the pointer representation is smaller than the integer type, otherwise the bits are unchanged.
A cast from integer to pointer discards most-significant bits if the pointer representation is smaller than the integer type, extends according to the signedness of the integer type if the pointer representation is larger than the integer type, otherwise the bits are unchanged.
When casting from pointer to integer and back again, the resulting pointer must reference the same object as the original pointer, otherwise the behavior is undefined. That is, one may not use integer arithmetic to avoid the undefined behavior of pointer arithmetic as proscribed in C99 6.5.6/8.
The value is as specified in the standard and the type is determined by the ABI.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
register
storage-class specifier are effective (C90 6.5.1, C99 6.7.1).
The register
specifier affects code generation only in these ways:
register
storage-class specifier; if register
is specified, the variable
may have a shorter lifespan than the code would indicate and may never
be placed in memory.
setjmp
doesn't save the registers in
all circumstances. In those cases, GCC doesn't allocate any variables
in registers unless they are marked register
.
GCC will not inline any functions if the `-fno-inline' option is used or if `-O0' is used. Otherwise, GCC may still be unable to inline a function for many reasons; the `-Winline' option may be used to determine if a function has not been inlined and why not.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The relevant bytes of the representation of the object are treated as an object of the type used for the access. See Type-punning. This may be a trap representation.
int
bit-field is treated as a
signed int
bit-field or as an unsigned int
bit-field
(C90 6.5.2, C90 6.5.2.1, C99 6.7.2, C99 6.7.2.1).
By default it is treated as signed int
but this may be changed
by the `-funsigned-bitfields' option.
_Bool
, signed int
,
and unsigned int
(C99 6.7.2.1).
No other types are permitted in strictly conforming mode.
Determined by ABI.
Determined by ABI.
Determined by ABI.
Normally, the type is unsigned int
if there are no negative
values in the enumeration, otherwise int
. If
`-fshort-enums' is specified, then if there are negative values
it is the first of signed char
, short
and int
that can represent all the values, otherwise it is the first of
unsigned char
, unsigned short
and unsigned int
that can represent all the values.
On some targets, `-fshort-enums' is the default; this is determined by the ABI.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Such an object is normally accessed by pointers and used for accessing hardware. In most expressions, it is intuitively obvious what is a read and what is a write. For example
volatile int *dst = somevalue; volatile int *src = someothervalue; *dst = *src; |
will cause a read of the volatile object pointed to by src and store the
value into the volatile object pointed to by dst. There is no
guarantee that these reads and writes are atomic, especially for objects
larger than int
.
However, if the volatile storage is not being modified, and the value of the volatile storage is not used, then the situation is less obvious. For example
volatile int *src = somevalue; *src; |
According to the C standard, such an expression is an rvalue whose type
is the unqualified version of its original type, i.e. int
. Whether
GCC interprets this as a read of the volatile object being pointed to or
only as a request to evaluate the expression for its side-effects depends
on this type.
If it is a scalar type, or on most targets an aggregate type whose only member object is of a scalar type, or a union type whose member objects are of scalar types, the expression is interpreted by GCC as a read of the volatile object; in the other cases, the expression is only evaluated for its side-effects.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GCC is only limited by available memory.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
case
values in a switch
statement (C90 6.6.4.2).
GCC is only limited by available memory.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
See section `Implementation-defined behavior' in The C Preprocessor, for details of these aspects of implementation-defined behavior.
#include
directive are combined into a header
name (C90 6.8.2, C99 6.10.2).
#include
processing (C90 6.8.2, C99
6.10.2).
STDC #pragma
directive (C90 6.8.6, C99 6.10.6).
See section `Pragmas' in The C Preprocessor, for details of pragmas accepted by GCC on all targets. See section Pragmas Accepted by GCC, for details of target-specific pragmas.
__DATE__
and __TIME__
when
respectively, the date and time of translation are not available (C90
6.8.8, C99 6.10.8).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The behavior of most of these points are dependent on the implementation of the C library, and are not defined by GCC itself.
NULL
expands
(C90 7.1.6, C99 7.17).
In <stddef.h>
, NULL
expands to ((void *)0)
. GCC
does not provide the other headers which define NULL
and some
library implementations may use other definitions in those headers.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
<float.h>
, <limits.h>
, and <stdint.h>
(C90 and C99 5.2.4.2, C99 7.18.2, C99 7.18.3).
Determined by ABI.
Determined by ABI.
sizeof
operator (C90
6.3.3.4, C99 6.5.3.4).
Determined by ABI.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The behavior of these points are dependent on the implementation of the C library, and are not defined by GCC itself.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |