1 @c Copyright (C) 2001-2018 Free Software Foundation, Inc.
2 @c This is part of the GCC manual.
3 @c For copying conditions, see the file gcc.texi.
6 @chapter C Implementation-Defined Behavior
7 @cindex implementation-defined behavior, C language
9 A conforming implementation of ISO C is required to document its
10 choice of behavior in each of the areas that are designated
11 ``implementation defined''. The following lists all such areas,
12 along with the section numbers from the ISO/IEC 9899:1990, ISO/IEC
13 9899:1999 and ISO/IEC 9899:2011 standards. Some areas are only
14 implementation-defined in one version of the standard.
16 Some choices depend on the externally determined ABI for the platform
17 (including standard character encodings) which GCC follows; these are
18 listed as ``determined by ABI'' below. @xref{Compatibility, , Binary
19 Compatibility}, and @uref{http://gcc.gnu.org/readings.html}. Some
20 choices are documented in the preprocessor manual.
21 @xref{Implementation-defined behavior, , Implementation-defined
22 behavior, cpp, The C Preprocessor}. Some choices are made by the
23 library and operating system (or other environment when compiling for
24 a freestanding environment); refer to their documentation for details.
27 * Translation implementation::
28 * Environment implementation::
29 * Identifiers implementation::
30 * Characters implementation::
31 * Integers implementation::
32 * Floating point implementation::
33 * Arrays and pointers implementation::
34 * Hints implementation::
35 * Structures unions enumerations and bit-fields implementation::
36 * Qualifiers implementation::
37 * Declarators implementation::
38 * Statements implementation::
39 * Preprocessing directives implementation::
40 * Library functions implementation::
41 * Architecture implementation::
42 * Locale-specific behavior implementation::
45 @node Translation implementation
50 @cite{How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90,
51 C99 and C11 5.1.1.3).}
53 Diagnostics consist of all the output sent to stderr by GCC@.
56 @cite{Whether each nonempty sequence of white-space characters other than
57 new-line is retained or replaced by one space character in translation
58 phase 3 (C90, C99 and C11 5.1.1.2).}
60 @xref{Implementation-defined behavior, , Implementation-defined
61 behavior, cpp, The C Preprocessor}.
65 @node Environment implementation
68 The behavior of most of these points are dependent on the implementation
69 of the C library, and are not defined by GCC itself.
73 @cite{The mapping between physical source file multibyte characters
74 and the source character set in translation phase 1 (C90, C99 and C11
77 @xref{Implementation-defined behavior, , Implementation-defined
78 behavior, cpp, The C Preprocessor}.
82 @node Identifiers implementation
87 @cite{Which additional multibyte characters may appear in identifiers
88 and their correspondence to universal character names (C99 and C11 6.4.2).}
90 @xref{Implementation-defined behavior, , Implementation-defined
91 behavior, cpp, The C Preprocessor}.
94 @cite{The number of significant initial characters in an identifier
95 (C90 6.1.2, C90, C99 and C11 5.2.4.1, C99 and C11 6.4.2).}
97 For internal names, all characters are significant. For external names,
98 the number of significant characters are defined by the linker; for
99 almost all targets, all characters are significant.
102 @cite{Whether case distinctions are significant in an identifier with
103 external linkage (C90 6.1.2).}
105 This is a property of the linker. C99 and C11 require that case distinctions
106 are always significant in identifiers with external linkage and
107 systems without this property are not supported by GCC@.
111 @node Characters implementation
116 @cite{The number of bits in a byte (C90 3.4, C99 and C11 3.6).}
121 @cite{The values of the members of the execution character set (C90,
127 @cite{The unique value of the member of the execution character set produced
128 for each of the standard alphabetic escape sequences (C90, C99 and C11
134 @cite{The value of a @code{char} object into which has been stored any
135 character other than a member of the basic execution character set
136 (C90 6.1.2.5, C99 and C11 6.2.5).}
141 @cite{Which of @code{signed char} or @code{unsigned char} has the same
142 range, representation, and behavior as ``plain'' @code{char} (C90
143 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1).}
145 @opindex fsigned-char
146 @opindex funsigned-char
147 Determined by ABI@. The options @option{-funsigned-char} and
148 @option{-fsigned-char} change the default. @xref{C Dialect Options, ,
149 Options Controlling C Dialect}.
152 @cite{The mapping of members of the source character set (in character
153 constants and string literals) to members of the execution character
154 set (C90 6.1.3.4, C99 and C11 6.4.4.4, C90, C99 and C11 5.1.1.2).}
159 @cite{The value of an integer character constant containing more than one
160 character or containing a character or escape sequence that does not map
161 to a single-byte execution character (C90 6.1.3.4, C99 and C11 6.4.4.4).}
163 @xref{Implementation-defined behavior, , Implementation-defined
164 behavior, cpp, The C Preprocessor}.
167 @cite{The value of a wide character constant containing more than one
168 multibyte character or a single multibyte character that maps to
169 multiple members of the extended execution character set, or
170 containing a multibyte character or escape sequence not represented in
171 the extended execution character set (C90 6.1.3.4, C99 and C11
174 @xref{Implementation-defined behavior, , Implementation-defined
175 behavior, cpp, The C Preprocessor}.
178 @cite{The current locale used to convert a wide character constant consisting
179 of a single multibyte character that maps to a member of the extended
180 execution character set into a corresponding wide character code (C90
181 6.1.3.4, C99 and C11 6.4.4.4).}
183 @xref{Implementation-defined behavior, , Implementation-defined
184 behavior, cpp, The C Preprocessor}.
187 @cite{Whether differently-prefixed wide string literal tokens can be
188 concatenated and, if so, the treatment of the resulting multibyte
189 character sequence (C11 6.4.5).}
191 Such tokens may not be concatenated.
194 @cite{The current locale used to convert a wide string literal into
195 corresponding wide character codes (C90 6.1.4, C99 and C11 6.4.5).}
197 @xref{Implementation-defined behavior, , Implementation-defined
198 behavior, cpp, The C Preprocessor}.
201 @cite{The value of a string literal containing a multibyte character or escape
202 sequence not represented in the execution character set (C90 6.1.4,
205 @xref{Implementation-defined behavior, , Implementation-defined
206 behavior, cpp, The C Preprocessor}.
209 @cite{The encoding of any of @code{wchar_t}, @code{char16_t}, and
210 @code{char32_t} where the corresponding standard encoding macro
211 (@code{__STDC_ISO_10646__}, @code{__STDC_UTF_16__}, or
212 @code{__STDC_UTF_32__}) is not defined (C11 6.10.8.2).}
214 @xref{Implementation-defined behavior, , Implementation-defined
215 behavior, cpp, The C Preprocessor}. @code{char16_t} and
216 @code{char32_t} literals are always encoded in UTF-16 and UTF-32
221 @node Integers implementation
226 @cite{Any extended integer types that exist in the implementation (C99
229 GCC does not support any extended integer types.
230 @c The __mode__ attribute might create types of precisions not
231 @c otherwise supported, but the syntax isn't right for use everywhere
232 @c the standard type names might be used. Predefined typedefs should
233 @c be used if any extended integer types are to be defined. The
234 @c __int128_t and __uint128_t typedefs are not extended integer types
235 @c as they are generally longer than the ABI-specified intmax_t.
238 @cite{Whether signed integer types are represented using sign and magnitude,
239 two's complement, or one's complement, and whether the extraordinary value
240 is a trap representation or an ordinary value (C99 and C11 6.2.6.2).}
242 GCC supports only two's complement integer types, and all bit patterns
246 @cite{The rank of any extended integer type relative to another extended
247 integer type with the same precision (C99 and C11 6.3.1.1).}
249 GCC does not support any extended integer types.
250 @c If it did, there would only be one of each precision and signedness.
253 @cite{The result of, or the signal raised by, converting an integer to a
254 signed integer type when the value cannot be represented in an object of
255 that type (C90 6.2.1.2, C99 and C11 6.3.1.3).}
257 For conversion to a type of width @math{N}, the value is reduced
258 modulo @math{2^N} to be within range of the type; no signal is raised.
261 @cite{The results of some bitwise operations on signed integers (C90
262 6.3, C99 and C11 6.5).}
264 Bitwise operators act on the representation of the value including
265 both the sign and value bits, where the sign bit is considered
266 immediately above the highest-value value bit. Signed @samp{>>} acts
267 on negative numbers by sign extension.
269 As an extension to the C language, GCC does not use the latitude given in
270 C99 and C11 only to treat certain aspects of signed @samp{<<} as undefined.
271 However, @option{-fsanitize=shift} (and @option{-fsanitize=undefined}) will
272 diagnose such cases. They are also diagnosed where constant
273 expressions are required.
276 @cite{The sign of the remainder on integer division (C90 6.3.5).}
278 GCC always follows the C99 and C11 requirement that the result of division is
279 truncated towards zero.
283 @node Floating point implementation
284 @section Floating Point
288 @cite{The accuracy of the floating-point operations and of the library
289 functions in @code{<math.h>} and @code{<complex.h>} that return floating-point
290 results (C90, C99 and C11 5.2.4.2.2).}
292 The accuracy is unknown.
295 @cite{The rounding behaviors characterized by non-standard values
296 of @code{FLT_ROUNDS} @gol
297 (C90, C99 and C11 5.2.4.2.2).}
299 GCC does not use such values.
302 @cite{The evaluation methods characterized by non-standard negative
303 values of @code{FLT_EVAL_METHOD} (C99 and C11 5.2.4.2.2).}
305 GCC does not use such values.
308 @cite{The direction of rounding when an integer is converted to a
309 floating-point number that cannot exactly represent the original
310 value (C90 6.2.1.3, C99 and C11 6.3.1.4).}
312 C99 Annex F is followed.
315 @cite{The direction of rounding when a floating-point number is
316 converted to a narrower floating-point number (C90 6.2.1.4, C99 and C11
319 C99 Annex F is followed.
322 @cite{How the nearest representable value or the larger or smaller
323 representable value immediately adjacent to the nearest representable
324 value is chosen for certain floating constants (C90 6.1.3.1, C99 and C11
327 C99 Annex F is followed.
330 @cite{Whether and how floating expressions are contracted when not
331 disallowed by the @code{FP_CONTRACT} pragma (C99 and C11 6.5).}
333 Expressions are currently only contracted if @option{-ffp-contract=fast},
334 @option{-funsafe-math-optimizations} or @option{-ffast-math} are used.
335 This is subject to change.
338 @cite{The default state for the @code{FENV_ACCESS} pragma (C99 and C11
341 This pragma is not implemented, but the default is to ``off'' unless
342 @option{-frounding-math} is used in which case it is ``on''.
345 @cite{Additional floating-point exceptions, rounding modes, environments,
346 and classifications, and their macro names (C99 and C11 7.6, C99 and
349 This is dependent on the implementation of the C library, and is not
350 defined by GCC itself.
353 @cite{The default state for the @code{FP_CONTRACT} pragma (C99 and C11
356 This pragma is not implemented. Expressions are currently only
357 contracted if @option{-ffp-contract=fast},
358 @option{-funsafe-math-optimizations} or @option{-ffast-math} are used.
359 This is subject to change.
362 @cite{Whether the ``inexact'' floating-point exception can be raised
363 when the rounded result actually does equal the mathematical result
364 in an IEC 60559 conformant implementation (C99 F.9).}
366 This is dependent on the implementation of the C library, and is not
367 defined by GCC itself.
370 @cite{Whether the ``underflow'' (and ``inexact'') floating-point
371 exception can be raised when a result is tiny but not inexact in an
372 IEC 60559 conformant implementation (C99 F.9).}
374 This is dependent on the implementation of the C library, and is not
375 defined by GCC itself.
379 @node Arrays and pointers implementation
380 @section Arrays and Pointers
384 @cite{The result of converting a pointer to an integer or
385 vice versa (C90 6.3.4, C99 and C11 6.3.2.3).}
387 A cast from pointer to integer discards most-significant bits if the
388 pointer representation is larger than the integer type,
389 sign-extends@footnote{Future versions of GCC may zero-extend, or use
390 a target-defined @code{ptr_extend} pattern. Do not rely on sign extension.}
391 if the pointer representation is smaller than the integer type, otherwise
392 the bits are unchanged.
393 @c ??? We've always claimed that pointers were unsigned entities.
394 @c Shouldn't we therefore be doing zero-extension? If so, the bug
395 @c is in convert_to_integer, where we call type_for_size and request
396 @c a signed integral type. On the other hand, it might be most useful
397 @c for the target if we extend according to POINTERS_EXTEND_UNSIGNED.
399 A cast from integer to pointer discards most-significant bits if the
400 pointer representation is smaller than the integer type, extends according
401 to the signedness of the integer type if the pointer representation
402 is larger than the integer type, otherwise the bits are unchanged.
404 When casting from pointer to integer and back again, the resulting
405 pointer must reference the same object as the original pointer, otherwise
406 the behavior is undefined. That is, one may not use integer arithmetic to
407 avoid the undefined behavior of pointer arithmetic as proscribed in
411 @cite{The size of the result of subtracting two pointers to elements
412 of the same array (C90 6.3.6, C99 and C11 6.5.6).}
414 The value is as specified in the standard and the type is determined
419 @node Hints implementation
424 @cite{The extent to which suggestions made by using the @code{register}
425 storage-class specifier are effective (C90 6.5.1, C99 and C11 6.7.1).}
427 The @code{register} specifier affects code generation only in these ways:
431 When used as part of the register variable extension, see
432 @ref{Explicit Register Variables}.
435 When @option{-O0} is in use, the compiler allocates distinct stack
436 memory for all variables that do not have the @code{register}
437 storage-class specifier; if @code{register} is specified, the variable
438 may have a shorter lifespan than the code would indicate and may never
442 On some rare x86 targets, @code{setjmp} doesn't save the registers in
443 all circumstances. In those cases, GCC doesn't allocate any variables
444 in registers unless they are marked @code{register}.
449 @cite{The extent to which suggestions made by using the inline function
450 specifier are effective (C99 and C11 6.7.4).}
452 GCC will not inline any functions if the @option{-fno-inline} option is
453 used or if @option{-O0} is used. Otherwise, GCC may still be unable to
454 inline a function for many reasons; the @option{-Winline} option may be
455 used to determine if a function has not been inlined and why not.
459 @node Structures unions enumerations and bit-fields implementation
460 @section Structures, Unions, Enumerations, and Bit-Fields
464 @cite{A member of a union object is accessed using a member of a
465 different type (C90 6.3.2.3).}
467 The relevant bytes of the representation of the object are treated as
468 an object of the type used for the access. @xref{Type-punning}. This
469 may be a trap representation.
472 @cite{Whether a ``plain'' @code{int} bit-field is treated as a
473 @code{signed int} bit-field or as an @code{unsigned int} bit-field
474 (C90 6.5.2, C90 6.5.2.1, C99 and C11 6.7.2, C99 and C11 6.7.2.1).}
476 @opindex funsigned-bitfields
477 By default it is treated as @code{signed int} but this may be changed
478 by the @option{-funsigned-bitfields} option.
481 @cite{Allowable bit-field types other than @code{_Bool}, @code{signed int},
482 and @code{unsigned int} (C99 and C11 6.7.2.1).}
484 Other integer types, such as @code{long int}, and enumerated types are
485 permitted even in strictly conforming mode.
488 @cite{Whether atomic types are permitted for bit-fields (C11 6.7.2.1).}
490 Atomic types are not permitted for bit-fields.
493 @cite{Whether a bit-field can straddle a storage-unit boundary (C90
494 6.5.2.1, C99 and C11 6.7.2.1).}
499 @cite{The order of allocation of bit-fields within a unit (C90
500 6.5.2.1, C99 and C11 6.7.2.1).}
505 @cite{The alignment of non-bit-field members of structures (C90
506 6.5.2.1, C99 and C11 6.7.2.1).}
511 @cite{The integer type compatible with each enumerated type (C90
512 6.5.2.2, C99 and C11 6.7.2.2).}
514 @opindex fshort-enums
515 Normally, the type is @code{unsigned int} if there are no negative
516 values in the enumeration, otherwise @code{int}. If
517 @option{-fshort-enums} is specified, then if there are negative values
518 it is the first of @code{signed char}, @code{short} and @code{int}
519 that can represent all the values, otherwise it is the first of
520 @code{unsigned char}, @code{unsigned short} and @code{unsigned int}
521 that can represent all the values.
522 @c On a few unusual targets with 64-bit int, this doesn't agree with
523 @c the code and one of the types accessed via mode attributes (which
524 @c are not currently considered extended integer types) may be used.
525 @c If these types are made extended integer types, it would still be
526 @c the case that -fshort-enums stops the implementation from
527 @c conforming to C90 on those targets.
529 On some targets, @option{-fshort-enums} is the default; this is
530 determined by the ABI@.
534 @node Qualifiers implementation
539 @cite{What constitutes an access to an object that has volatile-qualified
540 type (C90 6.5.3, C99 and C11 6.7.3).}
542 Such an object is normally accessed by pointers and used for accessing
543 hardware. In most expressions, it is intuitively obvious what is a read
544 and what is a write. For example
547 volatile int *dst = @var{somevalue};
548 volatile int *src = @var{someothervalue};
553 will cause a read of the volatile object pointed to by @var{src} and store the
554 value into the volatile object pointed to by @var{dst}. There is no
555 guarantee that these reads and writes are atomic, especially for objects
556 larger than @code{int}.
558 However, if the volatile storage is not being modified, and the value of
559 the volatile storage is not used, then the situation is less obvious.
563 volatile int *src = @var{somevalue};
567 According to the C standard, such an expression is an rvalue whose type
568 is the unqualified version of its original type, i.e. @code{int}. Whether
569 GCC interprets this as a read of the volatile object being pointed to or
570 only as a request to evaluate the expression for its side effects depends
573 If it is a scalar type, or on most targets an aggregate type whose only
574 member object is of a scalar type, or a union type whose member objects
575 are of scalar types, the expression is interpreted by GCC as a read of
576 the volatile object; in the other cases, the expression is only evaluated
577 for its side effects.
581 @node Declarators implementation
586 @cite{The maximum number of declarators that may modify an arithmetic,
587 structure or union type (C90 6.5.4).}
589 GCC is only limited by available memory.
593 @node Statements implementation
598 @cite{The maximum number of @code{case} values in a @code{switch}
599 statement (C90 6.6.4.2).}
601 GCC is only limited by available memory.
605 @node Preprocessing directives implementation
606 @section Preprocessing Directives
608 @xref{Implementation-defined behavior, , Implementation-defined
609 behavior, cpp, The C Preprocessor}, for details of these aspects of
610 implementation-defined behavior.
614 @cite{The locations within @code{#pragma} directives where header name
615 preprocessing tokens are recognized (C11 6.4, C11 6.4.7).}
618 @cite{How sequences in both forms of header names are mapped to headers
619 or external source file names (C90 6.1.7, C99 and C11 6.4.7).}
622 @cite{Whether the value of a character constant in a constant expression
623 that controls conditional inclusion matches the value of the same character
624 constant in the execution character set (C90 6.8.1, C99 and C11 6.10.1).}
627 @cite{Whether the value of a single-character character constant in a
628 constant expression that controls conditional inclusion may have a
629 negative value (C90 6.8.1, C99 and C11 6.10.1).}
632 @cite{The places that are searched for an included @samp{<>} delimited
633 header, and how the places are specified or the header is
634 identified (C90 6.8.2, C99 and C11 6.10.2).}
637 @cite{How the named source file is searched for in an included @samp{""}
638 delimited header (C90 6.8.2, C99 and C11 6.10.2).}
641 @cite{The method by which preprocessing tokens (possibly resulting from
642 macro expansion) in a @code{#include} directive are combined into a header
643 name (C90 6.8.2, C99 and C11 6.10.2).}
646 @cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99
650 @cite{Whether the @samp{#} operator inserts a @samp{\} character before
651 the @samp{\} character that begins a universal character name in a
652 character constant or string literal (C99 and C11 6.10.3.2).}
655 @cite{The behavior on each recognized non-@code{STDC #pragma}
656 directive (C90 6.8.6, C99 and C11 6.10.6).}
658 @xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of
659 pragmas accepted by GCC on all targets. @xref{Pragmas, , Pragmas
660 Accepted by GCC}, for details of target-specific pragmas.
663 @cite{The definitions for @code{__DATE__} and @code{__TIME__} when
664 respectively, the date and time of translation are not available (C90
665 6.8.8, C99 6.10.8, C11 6.10.8.1).}
669 @node Library functions implementation
670 @section Library Functions
672 The behavior of most of these points are dependent on the implementation
673 of the C library, and are not defined by GCC itself.
677 @cite{The null pointer constant to which the macro @code{NULL} expands
678 (C90 7.1.6, C99 7.17, C11 7.19).}
680 In @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}. GCC
681 does not provide the other headers which define @code{NULL} and some
682 library implementations may use other definitions in those headers.
686 @node Architecture implementation
687 @section Architecture
691 @cite{The values or expressions assigned to the macros specified in the
692 headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>}
693 (C90, C99 and C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11 7.20.2, C11 7.20.3).}
698 @cite{The result of attempting to indirectly access an object with
699 automatic or thread storage duration from a thread other than the one
700 with which it is associated (C11 6.2.4).}
702 Such accesses are supported, subject to the same requirements for
703 synchronization for concurrent accesses as for concurrent accesses to
707 @cite{The number, order, and encoding of bytes in any object
708 (when not explicitly specified in this International Standard) (C99
714 @cite{Whether any extended alignments are supported and the contexts
715 in which they are supported (C11 6.2.8).}
717 Extended alignments up to @math{2^{28}} (bytes) are supported for
718 objects of automatic storage duration. Alignments supported for
719 objects of static and thread storage duration are determined by the
723 @cite{Valid alignment values other than those returned by an _Alignof
724 expression for fundamental types, if any (C11 6.2.8).}
726 Valid alignments are powers of 2 up to and including @math{2^{28}}.
729 @cite{The value of the result of the @code{sizeof} and @code{_Alignof}
730 operators (C90 6.3.3.4, C99 and C11 6.5.3.4).}
736 @node Locale-specific behavior implementation
737 @section Locale-Specific Behavior
739 The behavior of these points are dependent on the implementation
740 of the C library, and are not defined by GCC itself.