1 @c Copyright (C) 2001,2002,2003,2004 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 and ISO/IEC
13 9899:1999 standards. Some areas are only implementation-defined in
14 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 3.10, C90 and C99 5.1.1.3).}
52 Diagnostics consist of all the output sent to stderr by GCC@.
55 @cite{Whether each nonempty sequence of white-space characters other than
56 new-line is retained or replaced by one space character in translation
57 phase 3 (C90 and C99 5.1.1.2).}
59 @xref{Implementation-defined behavior, , Implementation-defined
60 behavior, cpp, The C Preprocessor}.
64 @node Environment implementation
67 The behavior of most of these points are dependent on the implementation
68 of the C library, and are not defined by GCC itself.
72 @cite{The mapping between physical source file multibyte characters
73 and the source character set in translation phase 1 (C90 and C99 5.1.1.2).}
75 @xref{Implementation-defined behavior, , Implementation-defined
76 behavior, cpp, The C Preprocessor}.
80 @node Identifiers implementation
85 @cite{Which additional multibyte characters may appear in identifiers
86 and their correspondence to universal character names (C99 6.4.2).}
88 @xref{Implementation-defined behavior, , Implementation-defined
89 behavior, cpp, The C Preprocessor}.
92 @cite{The number of significant initial characters in an identifier
93 (C90 6.1.2, C90 and C99 5.2.4.1, C99 6.4.2).}
95 For internal names, all characters are significant. For external names,
96 the number of significant characters are defined by the linker; for
97 almost all targets, all characters are significant.
100 @cite{Whether case distinctions are significant in an identifier with
101 external linkage (C90 6.1.2).}
103 This is a property of the linker. C99 requires that case distinctions
104 are always significant in identifiers with external linkage and
105 systems without this property are not supported by GCC@.
109 @node Characters implementation
114 @cite{The number of bits in a byte (C90 3.4, C99 3.6).}
119 @cite{The values of the members of the execution character set (C90
125 @cite{The unique value of the member of the execution character set produced
126 for each of the standard alphabetic escape sequences (C90 and C99 5.2.2).}
131 @cite{The value of a @code{char} object into which has been stored any
132 character other than a member of the basic execution character set
133 (C90 6.1.2.5, C99 6.2.5).}
138 @cite{Which of @code{signed char} or @code{unsigned char} has the same
139 range, representation, and behavior as ``plain'' @code{char} (C90
140 6.1.2.5, C90 6.2.1.1, C99 6.2.5, C99 6.3.1.1).}
142 @opindex fsigned-char
143 @opindex funsigned-char
144 Determined by ABI@. The options @option{-funsigned-char} and
145 @option{-fsigned-char} change the default. @xref{C Dialect Options, ,
146 Options Controlling C Dialect}.
149 @cite{The mapping of members of the source character set (in character
150 constants and string literals) to members of the execution character
151 set (C90 6.1.3.4, C99 6.4.4.4, C90 and C99 5.1.1.2).}
156 @cite{The value of an integer character constant containing more than one
157 character or containing a character or escape sequence that does not map
158 to a single-byte execution character (C90 6.1.3.4, C99 6.4.4.4).}
160 @xref{Implementation-defined behavior, , Implementation-defined
161 behavior, cpp, The C Preprocessor}.
164 @cite{The value of a wide character constant containing more than one
165 multibyte character, or containing a multibyte character or escape
166 sequence not represented in the extended execution character set (C90
167 6.1.3.4, C99 6.4.4.4).}
169 @xref{Implementation-defined behavior, , Implementation-defined
170 behavior, cpp, The C Preprocessor}.
173 @cite{The current locale used to convert a wide character constant consisting
174 of a single multibyte character that maps to a member of the extended
175 execution character set into a corresponding wide character code (C90
176 6.1.3.4, C99 6.4.4.4).}
178 @xref{Implementation-defined behavior, , Implementation-defined
179 behavior, cpp, The C Preprocessor}.
182 @cite{The current locale used to convert a wide string literal into
183 corresponding wide character codes (C90 6.1.4, C99 6.4.5).}
185 @xref{Implementation-defined behavior, , Implementation-defined
186 behavior, cpp, The C Preprocessor}.
189 @cite{The value of a string literal containing a multibyte character or escape
190 sequence not represented in the execution character set (C90 6.1.4, C99 6.4.5).}
192 @xref{Implementation-defined behavior, , Implementation-defined
193 behavior, cpp, The C Preprocessor}.
196 @node Integers implementation
201 @cite{Any extended integer types that exist in the implementation (C99 6.2.5).}
203 GCC does not support any extended integer types.
204 @c The __mode__ attribute might create types of precisions not
205 @c otherwise supported, but the syntax isn't right for use everywhere
206 @c the standard type names might be used. Predefined typedefs should
207 @c be used if any extended integer types are to be defined. The
208 @c __int128_t and __uint128_t typedefs are not extended integer types
209 @c as they are generally longer than the ABI-specified intmax_t.
212 @cite{Whether signed integer types are represented using sign and magnitude,
213 two's complement, or one's complement, and whether the extraordinary value
214 is a trap representation or an ordinary value (C99 6.2.6.2).}
216 GCC supports only two's complement integer types, and all bit patterns
220 @cite{The rank of any extended integer type relative to another extended
221 integer type with the same precision (C99 6.3.1.1).}
223 GCC does not support any extended integer types.
224 @c If it did, there would only be one of each precision and signedness.
227 @cite{The result of, or the signal raised by, converting an integer to a
228 signed integer type when the value cannot be represented in an object of
229 that type (C90 6.2.1.2, C99 6.3.1.3).}
231 For conversion to a type of width @math{N}, the value is reduced
232 modulo @math{2^N} to be within range of the type; no signal is raised.
235 @cite{The results of some bitwise operations on signed integers (C90
238 Bitwise operators act on the representation of the value including
239 both the sign and value bits, where the sign bit is considered
240 immediately above the highest-value value bit. Signed @samp{>>} acts
241 on negative numbers by sign extension.
243 GCC does not use the latitude given in C99 only to treat certain
244 aspects of signed @samp{<<} as undefined, but this is subject to
248 @cite{The sign of the remainder on integer division (C90 6.3.5).}
250 GCC always follows the C99 requirement that the result of division is
251 truncated towards zero.
255 @node Floating point implementation
256 @section Floating point
260 @cite{The accuracy of the floating-point operations and of the library
261 functions in @code{<math.h>} and @code{<complex.h>} that return floating-point
262 results (C90 and C99 5.2.4.2.2).}
264 The accuracy is unknown.
267 @cite{The rounding behaviors characterized by non-standard values
268 of @code{FLT_ROUNDS} @gol
269 (C90 and C99 5.2.4.2.2).}
271 GCC does not use such values.
274 @cite{The evaluation methods characterized by non-standard negative
275 values of @code{FLT_EVAL_METHOD} (C99 5.2.4.2.2).}
277 GCC does not use such values.
280 @cite{The direction of rounding when an integer is converted to a
281 floating-point number that cannot exactly represent the original
282 value (C90 6.2.1.3, C99 6.3.1.4).}
284 C99 Annex F is followed.
287 @cite{The direction of rounding when a floating-point number is
288 converted to a narrower floating-point number (C90 6.2.1.4, C99
291 C99 Annex F is followed.
294 @cite{How the nearest representable value or the larger or smaller
295 representable value immediately adjacent to the nearest representable
296 value is chosen for certain floating constants (C90 6.1.3.1, C99
299 C99 Annex F is followed.
302 @cite{Whether and how floating expressions are contracted when not
303 disallowed by the @code{FP_CONTRACT} pragma (C99 6.5).}
305 Expressions are currently only contracted if
306 @option{-funsafe-math-optimizations} or @option{-ffast-math} are used.
307 This is subject to change.
310 @cite{The default state for the @code{FENV_ACCESS} pragma (C99 7.6.1).}
312 This pragma is not implemented, but the default is to ``off'' unless
313 @option{-frounding-math} is used in which case it is ``on''.
316 @cite{Additional floating-point exceptions, rounding modes, environments,
317 and classifications, and their macro names (C99 7.6, C99 7.12).}
319 This is dependent on the implementation of the C library, and is not
320 defined by GCC itself.
323 @cite{The default state for the @code{FP_CONTRACT} pragma (C99 7.12.2).}
325 This pragma is not implemented. Expressions are currently only
326 contracted if @option{-funsafe-math-optimizations} or
327 @option{-ffast-math} are used. This is subject to change.
330 @cite{Whether the ``inexact'' floating-point exception can be raised
331 when the rounded result actually does equal the mathematical result
332 in an IEC 60559 conformant implementation (C99 F.9).}
334 This is dependent on the implementation of the C library, and is not
335 defined by GCC itself.
338 @cite{Whether the ``underflow'' (and ``inexact'') floating-point
339 exception can be raised when a result is tiny but not inexact in an
340 IEC 60559 conformant implementation (C99 F.9).}
342 This is dependent on the implementation of the C library, and is not
343 defined by GCC itself.
347 @node Arrays and pointers implementation
348 @section Arrays and pointers
352 @cite{The result of converting a pointer to an integer or
353 vice versa (C90 6.3.4, C99 6.3.2.3).}
355 A cast from pointer to integer discards most-significant bits if the
356 pointer representation is larger than the integer type,
357 sign-extends@footnote{Future versions of GCC may zero-extend, or use
358 a target-defined @code{ptr_extend} pattern. Do not rely on sign extension.}
359 if the pointer representation is smaller than the integer type, otherwise
360 the bits are unchanged.
361 @c ??? We've always claimed that pointers were unsigned entities.
362 @c Shouldn't we therefore be doing zero-extension? If so, the bug
363 @c is in convert_to_integer, where we call type_for_size and request
364 @c a signed integral type. On the other hand, it might be most useful
365 @c for the target if we extend according to POINTERS_EXTEND_UNSIGNED.
367 A cast from integer to pointer discards most-significant bits if the
368 pointer representation is smaller than the integer type, extends according
369 to the signedness of the integer type if the pointer representation
370 is larger than the integer type, otherwise the bits are unchanged.
372 When casting from pointer to integer and back again, the resulting
373 pointer must reference the same object as the original pointer, otherwise
374 the behavior is undefined. That is, one may not use integer arithmetic to
375 avoid the undefined behavior of pointer arithmetic as proscribed in
379 @cite{The size of the result of subtracting two pointers to elements
380 of the same array (C90 6.3.6, C99 6.5.6).}
382 The value is as specified in the standard and the type is determined
387 @node Hints implementation
392 @cite{The extent to which suggestions made by using the @code{register}
393 storage-class specifier are effective (C90 6.5.1, C99 6.7.1).}
395 The @code{register} specifier affects code generation only in these ways:
399 When used as part of the register variable extension, see
400 @ref{Explicit Reg Vars}.
403 When @option{-O0} is in use, the compiler allocates distinct stack
404 memory for all variables that do not have the @code{register}
405 storage-class specifier; if @code{register} is specified, the variable
406 may have a shorter lifespan than the code would indicate and may never
410 On some rare x86 targets, @code{setjmp} doesn't save the registers in
411 all circumstances. In those cases, GCC doesn't allocate any variables
412 in registers unless they are marked @code{register}.
417 @cite{The extent to which suggestions made by using the inline function
418 specifier are effective (C99 6.7.4).}
420 GCC will not inline any functions if the @option{-fno-inline} option is
421 used or if @option{-O0} is used. Otherwise, GCC may still be unable to
422 inline a function for many reasons; the @option{-Winline} option may be
423 used to determine if a function has not been inlined and why not.
427 @node Structures unions enumerations and bit-fields implementation
428 @section Structures, unions, enumerations, and bit-fields
432 @cite{A member of a union object is accessed using a member of a
433 different type (C90 6.3.2.3).}
435 The relevant bytes of the representation of the object are treated as
436 an object of the type used for the access. This may be a trap
440 @cite{Whether a ``plain'' @code{int} bit-field is treated as a
441 @code{signed int} bit-field or as an @code{unsigned int} bit-field
442 (C90 6.5.2, C90 6.5.2.1, C99 6.7.2, C99 6.7.2.1).}
444 @opindex funsigned-bitfields
445 By default it is treated as @code{signed int} but this may be changed
446 by the @option{-funsigned-bitfields} option.
449 @cite{Allowable bit-field types other than @code{_Bool}, @code{signed int},
450 and @code{unsigned int} (C99 6.7.2.1).}
452 No other types are permitted in strictly conforming mode.
453 @c Would it be better to restrict the pedwarn for other types to C90
454 @c mode and document the other types for C99 mode?
457 @cite{Whether a bit-field can straddle a storage-unit boundary (C90
458 6.5.2.1, C99 6.7.2.1).}
463 @cite{The order of allocation of bit-fields within a unit (C90
464 6.5.2.1, C99 6.7.2.1).}
469 @cite{The alignment of non-bit-field members of structures (C90
470 6.5.2.1, C99 6.7.2.1).}
475 @cite{The integer type compatible with each enumerated type (C90
476 6.5.2.2, C99 6.7.2.2).}
478 @opindex fshort-enums
479 Normally, the type is @code{unsigned int} if there are no negative
480 values in the enumeration, otherwise @code{int}. If
481 @option{-fshort-enums} is specified, then if there are negative values
482 it is the first of @code{signed char}, @code{short} and @code{int}
483 that can represent all the values, otherwise it is the first of
484 @code{unsigned char}, @code{unsigned short} and @code{unsigned int}
485 that can represent all the values.
486 @c On a few unusual targets with 64-bit int, this doesn't agree with
487 @c the code and one of the types accessed via mode attributes (which
488 @c are not currently considered extended integer types) may be used.
489 @c If these types are made extended integer types, it would still be
490 @c the case that -fshort-enums stops the implementation from
491 @c conforming to C90 on those targets.
493 On some targets, @option{-fshort-enums} is the default; this is
494 determined by the ABI@.
498 @node Qualifiers implementation
503 @cite{What constitutes an access to an object that has volatile-qualified
504 type (C90 6.5.3, C99 6.7.3).}
506 Such an object is normally accessed by pointers and used for accessing
507 hardware. In most expressions, it is intuitively obvious what is a read
508 and what is a write. For example
511 volatile int *dst = @var{somevalue};
512 volatile int *src = @var{someothervalue};
517 will cause a read of the volatile object pointed to by @var{src} and store the
518 value into the volatile object pointed to by @var{dst}. There is no
519 guarantee that these reads and writes are atomic, especially for objects
520 larger than @code{int}.
522 However, if the volatile storage is not being modified, and the value of
523 the volatile storage is not used, then the situation is less obvious.
527 volatile int *src = @var{somevalue};
531 According to the C standard, such an expression is an rvalue whose type
532 is the unqualified version of its original type, i.e. @code{int}. Whether
533 GCC interprets this as a read of the volatile object being pointed to or
534 only as a request to evaluate the expression for its side-effects depends
537 If it is a scalar type, or on most targets an aggregate type whose only
538 member object is of a scalar type, or a union type whose member objects
539 are of scalar types, the expression is interpreted by GCC as a read of
540 the volatile object; in the other cases, the expression is only evaluated
541 for its side-effects.
545 @node Declarators implementation
550 @cite{The maximum number of declarators that may modify an arithmetic,
551 structure or union type (C90 6.5.4).}
553 GCC is only limited by available memory.
557 @node Statements implementation
562 @cite{The maximum number of @code{case} values in a @code{switch}
563 statement (C90 6.6.4.2).}
565 GCC is only limited by available memory.
569 @node Preprocessing directives implementation
570 @section Preprocessing directives
572 @xref{Implementation-defined behavior, , Implementation-defined
573 behavior, cpp, The C Preprocessor}, for details of these aspects of
574 implementation-defined behavior.
578 @cite{How sequences in both forms of header names are mapped to headers
579 or external source file names (C90 6.1.7, C99 6.4.7).}
582 @cite{Whether the value of a character constant in a constant expression
583 that controls conditional inclusion matches the value of the same character
584 constant in the execution character set (C90 6.8.1, C99 6.10.1).}
587 @cite{Whether the value of a single-character character constant in a
588 constant expression that controls conditional inclusion may have a
589 negative value (C90 6.8.1, C99 6.10.1).}
592 @cite{The places that are searched for an included @samp{<>} delimited
593 header, and how the places are specified or the header is
594 identified (C90 6.8.2, C99 6.10.2).}
597 @cite{How the named source file is searched for in an included @samp{""}
598 delimited header (C90 6.8.2, C99 6.10.2).}
601 @cite{The method by which preprocessing tokens (possibly resulting from
602 macro expansion) in a @code{#include} directive are combined into a header
603 name (C90 6.8.2, C99 6.10.2).}
606 @cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99
610 @cite{Whether the @samp{#} operator inserts a @samp{\} character before
611 the @samp{\} character that begins a universal character name in a
612 character constant or string literal (C99 6.10.3.2).}
615 @cite{The behavior on each recognized non-@code{STDC #pragma}
616 directive (C90 6.8.6, C99 6.10.6).}
618 @xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of
619 pragmas accepted by GCC on all targets. @xref{Pragmas, , Pragmas
620 Accepted by GCC}, for details of target-specific pragmas.
623 @cite{The definitions for @code{__DATE__} and @code{__TIME__} when
624 respectively, the date and time of translation are not available (C90
629 @node Library functions implementation
630 @section Library functions
632 The behavior of most of these points are dependent on the implementation
633 of the C library, and are not defined by GCC itself.
637 @cite{The null pointer constant to which the macro @code{NULL} expands
638 (C90 7.1.6, C99 7.17).}
640 In @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}. GCC
641 does not provide the other headers which define @code{NULL} and some
642 library implementations may use other definitions in those headers.
646 @node Architecture implementation
647 @section Architecture
651 @cite{The values or expressions assigned to the macros specified in the
652 headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>}
653 (C90 and C99 5.2.4.2, C99 7.18.2, C99 7.18.3).}
658 @cite{The number, order, and encoding of bytes in any object
659 (when not explicitly specified in this International Standard) (C99 6.2.6.1).}
664 @cite{The value of the result of the @code{sizeof} operator (C90
665 6.3.3.4, C99 6.5.3.4).}
671 @node Locale-specific behavior implementation
672 @section Locale-specific behavior
674 The behavior of these points are dependent on the implementation
675 of the C library, and are not defined by GCC itself.