1 @c Copyright (C) 2001-2013 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 GCC does not use the latitude given in C99 and C11 only to treat certain
270 aspects of signed @samp{<<} as undefined, but this is subject to
274 @cite{The sign of the remainder on integer division (C90 6.3.5).}
276 GCC always follows the C99 and C11 requirement that the result of division is
277 truncated towards zero.
281 @node Floating point implementation
282 @section Floating point
286 @cite{The accuracy of the floating-point operations and of the library
287 functions in @code{<math.h>} and @code{<complex.h>} that return floating-point
288 results (C90, C99 and C11 5.2.4.2.2).}
290 The accuracy is unknown.
293 @cite{The rounding behaviors characterized by non-standard values
294 of @code{FLT_ROUNDS} @gol
295 (C90, C99 and C11 5.2.4.2.2).}
297 GCC does not use such values.
300 @cite{The evaluation methods characterized by non-standard negative
301 values of @code{FLT_EVAL_METHOD} (C99 and C11 5.2.4.2.2).}
303 GCC does not use such values.
306 @cite{The direction of rounding when an integer is converted to a
307 floating-point number that cannot exactly represent the original
308 value (C90 6.2.1.3, C99 and C11 6.3.1.4).}
310 C99 Annex F is followed.
313 @cite{The direction of rounding when a floating-point number is
314 converted to a narrower floating-point number (C90 6.2.1.4, C99 and C11
317 C99 Annex F is followed.
320 @cite{How the nearest representable value or the larger or smaller
321 representable value immediately adjacent to the nearest representable
322 value is chosen for certain floating constants (C90 6.1.3.1, C99 and C11
325 C99 Annex F is followed.
328 @cite{Whether and how floating expressions are contracted when not
329 disallowed by the @code{FP_CONTRACT} pragma (C99 and C11 6.5).}
331 Expressions are currently only contracted if @option{-ffp-contract=fast},
332 @option{-funsafe-math-optimizations} or @option{-ffast-math} are used.
333 This is subject to change.
336 @cite{The default state for the @code{FENV_ACCESS} pragma (C99 and C11
339 This pragma is not implemented, but the default is to ``off'' unless
340 @option{-frounding-math} is used in which case it is ``on''.
343 @cite{Additional floating-point exceptions, rounding modes, environments,
344 and classifications, and their macro names (C99 and C11 7.6, C99 and
347 This is dependent on the implementation of the C library, and is not
348 defined by GCC itself.
351 @cite{The default state for the @code{FP_CONTRACT} pragma (C99 and C11
354 This pragma is not implemented. Expressions are currently only
355 contracted if @option{-ffp-contract=fast},
356 @option{-funsafe-math-optimizations} or @option{-ffast-math} are used.
357 This is subject to change.
360 @cite{Whether the ``inexact'' floating-point exception can be raised
361 when the rounded result actually does equal the mathematical result
362 in an IEC 60559 conformant implementation (C99 F.9).}
364 This is dependent on the implementation of the C library, and is not
365 defined by GCC itself.
368 @cite{Whether the ``underflow'' (and ``inexact'') floating-point
369 exception can be raised when a result is tiny but not inexact in an
370 IEC 60559 conformant implementation (C99 F.9).}
372 This is dependent on the implementation of the C library, and is not
373 defined by GCC itself.
377 @node Arrays and pointers implementation
378 @section Arrays and pointers
382 @cite{The result of converting a pointer to an integer or
383 vice versa (C90 6.3.4, C99 and C11 6.3.2.3).}
385 A cast from pointer to integer discards most-significant bits if the
386 pointer representation is larger than the integer type,
387 sign-extends@footnote{Future versions of GCC may zero-extend, or use
388 a target-defined @code{ptr_extend} pattern. Do not rely on sign extension.}
389 if the pointer representation is smaller than the integer type, otherwise
390 the bits are unchanged.
391 @c ??? We've always claimed that pointers were unsigned entities.
392 @c Shouldn't we therefore be doing zero-extension? If so, the bug
393 @c is in convert_to_integer, where we call type_for_size and request
394 @c a signed integral type. On the other hand, it might be most useful
395 @c for the target if we extend according to POINTERS_EXTEND_UNSIGNED.
397 A cast from integer to pointer discards most-significant bits if the
398 pointer representation is smaller than the integer type, extends according
399 to the signedness of the integer type if the pointer representation
400 is larger than the integer type, otherwise the bits are unchanged.
402 When casting from pointer to integer and back again, the resulting
403 pointer must reference the same object as the original pointer, otherwise
404 the behavior is undefined. That is, one may not use integer arithmetic to
405 avoid the undefined behavior of pointer arithmetic as proscribed in
409 @cite{The size of the result of subtracting two pointers to elements
410 of the same array (C90 6.3.6, C99 and C11 6.5.6).}
412 The value is as specified in the standard and the type is determined
417 @node Hints implementation
422 @cite{The extent to which suggestions made by using the @code{register}
423 storage-class specifier are effective (C90 6.5.1, C99 and C11 6.7.1).}
425 The @code{register} specifier affects code generation only in these ways:
429 When used as part of the register variable extension, see
430 @ref{Explicit Reg Vars}.
433 When @option{-O0} is in use, the compiler allocates distinct stack
434 memory for all variables that do not have the @code{register}
435 storage-class specifier; if @code{register} is specified, the variable
436 may have a shorter lifespan than the code would indicate and may never
440 On some rare x86 targets, @code{setjmp} doesn't save the registers in
441 all circumstances. In those cases, GCC doesn't allocate any variables
442 in registers unless they are marked @code{register}.
447 @cite{The extent to which suggestions made by using the inline function
448 specifier are effective (C99 and C11 6.7.4).}
450 GCC will not inline any functions if the @option{-fno-inline} option is
451 used or if @option{-O0} is used. Otherwise, GCC may still be unable to
452 inline a function for many reasons; the @option{-Winline} option may be
453 used to determine if a function has not been inlined and why not.
457 @node Structures unions enumerations and bit-fields implementation
458 @section Structures, unions, enumerations, and bit-fields
462 @cite{A member of a union object is accessed using a member of a
463 different type (C90 6.3.2.3).}
465 The relevant bytes of the representation of the object are treated as
466 an object of the type used for the access. @xref{Type-punning}. This
467 may be a trap representation.
470 @cite{Whether a ``plain'' @code{int} bit-field is treated as a
471 @code{signed int} bit-field or as an @code{unsigned int} bit-field
472 (C90 6.5.2, C90 6.5.2.1, C99 and C11 6.7.2, C99 and C11 6.7.2.1).}
474 @opindex funsigned-bitfields
475 By default it is treated as @code{signed int} but this may be changed
476 by the @option{-funsigned-bitfields} option.
479 @cite{Allowable bit-field types other than @code{_Bool}, @code{signed int},
480 and @code{unsigned int} (C99 and C11 6.7.2.1).}
482 No other types are permitted in strictly conforming mode.
483 @c Would it be better to restrict the pedwarn for other types to C90
484 @c mode and document the other types for C99/C11 mode?
487 @cite{Whether atomic types are permitted for bit-fields (C11 6.7.2.1).}
489 Atomic types are not permitted for bit-fields.
492 @cite{Whether a bit-field can straddle a storage-unit boundary (C90
493 6.5.2.1, C99 and C11 6.7.2.1).}
498 @cite{The order of allocation of bit-fields within a unit (C90
499 6.5.2.1, C99 and C11 6.7.2.1).}
504 @cite{The alignment of non-bit-field members of structures (C90
505 6.5.2.1, C99 and C11 6.7.2.1).}
510 @cite{The integer type compatible with each enumerated type (C90
511 6.5.2.2, C99 and C11 6.7.2.2).}
513 @opindex fshort-enums
514 Normally, the type is @code{unsigned int} if there are no negative
515 values in the enumeration, otherwise @code{int}. If
516 @option{-fshort-enums} is specified, then if there are negative values
517 it is the first of @code{signed char}, @code{short} and @code{int}
518 that can represent all the values, otherwise it is the first of
519 @code{unsigned char}, @code{unsigned short} and @code{unsigned int}
520 that can represent all the values.
521 @c On a few unusual targets with 64-bit int, this doesn't agree with
522 @c the code and one of the types accessed via mode attributes (which
523 @c are not currently considered extended integer types) may be used.
524 @c If these types are made extended integer types, it would still be
525 @c the case that -fshort-enums stops the implementation from
526 @c conforming to C90 on those targets.
528 On some targets, @option{-fshort-enums} is the default; this is
529 determined by the ABI@.
533 @node Qualifiers implementation
538 @cite{What constitutes an access to an object that has volatile-qualified
539 type (C90 6.5.3, C99 and C11 6.7.3).}
541 Such an object is normally accessed by pointers and used for accessing
542 hardware. In most expressions, it is intuitively obvious what is a read
543 and what is a write. For example
546 volatile int *dst = @var{somevalue};
547 volatile int *src = @var{someothervalue};
552 will cause a read of the volatile object pointed to by @var{src} and store the
553 value into the volatile object pointed to by @var{dst}. There is no
554 guarantee that these reads and writes are atomic, especially for objects
555 larger than @code{int}.
557 However, if the volatile storage is not being modified, and the value of
558 the volatile storage is not used, then the situation is less obvious.
562 volatile int *src = @var{somevalue};
566 According to the C standard, such an expression is an rvalue whose type
567 is the unqualified version of its original type, i.e. @code{int}. Whether
568 GCC interprets this as a read of the volatile object being pointed to or
569 only as a request to evaluate the expression for its side-effects depends
572 If it is a scalar type, or on most targets an aggregate type whose only
573 member object is of a scalar type, or a union type whose member objects
574 are of scalar types, the expression is interpreted by GCC as a read of
575 the volatile object; in the other cases, the expression is only evaluated
576 for its side-effects.
580 @node Declarators implementation
585 @cite{The maximum number of declarators that may modify an arithmetic,
586 structure or union type (C90 6.5.4).}
588 GCC is only limited by available memory.
592 @node Statements implementation
597 @cite{The maximum number of @code{case} values in a @code{switch}
598 statement (C90 6.6.4.2).}
600 GCC is only limited by available memory.
604 @node Preprocessing directives implementation
605 @section Preprocessing directives
607 @xref{Implementation-defined behavior, , Implementation-defined
608 behavior, cpp, The C Preprocessor}, for details of these aspects of
609 implementation-defined behavior.
613 @cite{The locations within @code{#pragma} directives where header name
614 preprocessing tokens are recognized (C11 6.4, C11 6.4.7).}
617 @cite{How sequences in both forms of header names are mapped to headers
618 or external source file names (C90 6.1.7, C99 and C11 6.4.7).}
621 @cite{Whether the value of a character constant in a constant expression
622 that controls conditional inclusion matches the value of the same character
623 constant in the execution character set (C90 6.8.1, C99 and C11 6.10.1).}
626 @cite{Whether the value of a single-character character constant in a
627 constant expression that controls conditional inclusion may have a
628 negative value (C90 6.8.1, C99 and C11 6.10.1).}
631 @cite{The places that are searched for an included @samp{<>} delimited
632 header, and how the places are specified or the header is
633 identified (C90 6.8.2, C99 and C11 6.10.2).}
636 @cite{How the named source file is searched for in an included @samp{""}
637 delimited header (C90 6.8.2, C99 and C11 6.10.2).}
640 @cite{The method by which preprocessing tokens (possibly resulting from
641 macro expansion) in a @code{#include} directive are combined into a header
642 name (C90 6.8.2, C99 and C11 6.10.2).}
645 @cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99
649 @cite{Whether the @samp{#} operator inserts a @samp{\} character before
650 the @samp{\} character that begins a universal character name in a
651 character constant or string literal (C99 and C11 6.10.3.2).}
654 @cite{The behavior on each recognized non-@code{STDC #pragma}
655 directive (C90 6.8.6, C99 and C11 6.10.6).}
657 @xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of
658 pragmas accepted by GCC on all targets. @xref{Pragmas, , Pragmas
659 Accepted by GCC}, for details of target-specific pragmas.
662 @cite{The definitions for @code{__DATE__} and @code{__TIME__} when
663 respectively, the date and time of translation are not available (C90
664 6.8.8, C99 6.10.8, C11 6.10.8.1).}
668 @node Library functions implementation
669 @section Library functions
671 The behavior of most of these points are dependent on the implementation
672 of the C library, and are not defined by GCC itself.
676 @cite{The null pointer constant to which the macro @code{NULL} expands
677 (C90 7.1.6, C99 7.17, C11 7.19).}
679 In @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}. GCC
680 does not provide the other headers which define @code{NULL} and some
681 library implementations may use other definitions in those headers.
685 @node Architecture implementation
686 @section Architecture
690 @cite{The values or expressions assigned to the macros specified in the
691 headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>}
692 (C90, C99 and C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11 7.20.2, C11 7.20.3).}
697 @cite{The result of attempting to indirectly access an object with
698 automatic or thread storage duration from a thread other than the one
699 with which it is associated (C11 6.2.4).}
701 Such accesses are supported, subject to the same requirements for
702 synchronization for concurrent accesses as for concurrent accesses to
706 @cite{The number, order, and encoding of bytes in any object
707 (when not explicitly specified in this International Standard) (C99
713 @cite{Whether any extended alignments are supported and the contexts
714 in which they are supported (C11 6.2.8).}
716 Extended alignments up to @math{2^{28}} (bytes) are supported for
717 objects of automatic storage duration. Alignments supported for
718 objects of static and thread storage duration are determined by the
722 @cite{Valid alignment values other than those returned by an _Alignof
723 expression for fundamental types, if any (C11 6.2.8).}
725 Valid alignments are powers of 2 up to and including @math{2^{28}}.
728 @cite{The value of the result of the @code{sizeof} and @code{_Alignof}
729 operators (C90 6.3.3.4, C99 and C11 6.5.3.4).}
735 @node Locale-specific behavior implementation
736 @section Locale-specific behavior
738 The behavior of these points are dependent on the implementation
739 of the C library, and are not defined by GCC itself.