1@c Copyright (C) 2001-2020 Free Software Foundation, Inc. 2@c This is part of the GCC manual. 3@c For copying conditions, see the file gcc.texi. 4 5@node C Implementation 6@chapter C Implementation-Defined Behavior 7@cindex implementation-defined behavior, C language 8 9A conforming implementation of ISO C is required to document its 10choice of behavior in each of the areas that are designated 11``implementation defined''. The following lists all such areas, 12along with the section numbers from the ISO/IEC 9899:1990, ISO/IEC 139899:1999 and ISO/IEC 9899:2011 standards. Some areas are only 14implementation-defined in one version of the standard. 15 16Some choices depend on the externally determined ABI for the platform 17(including standard character encodings) which GCC follows; these are 18listed as ``determined by ABI'' below. @xref{Compatibility, , Binary 19Compatibility}, and @uref{http://gcc.gnu.org/readings.html}. Some 20choices are documented in the preprocessor manual. 21@xref{Implementation-defined behavior, , Implementation-defined 22behavior, cpp, The C Preprocessor}. Some choices are made by the 23library and operating system (or other environment when compiling for 24a freestanding environment); refer to their documentation for details. 25 26@menu 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:: 43@end menu 44 45@node Translation implementation 46@section Translation 47 48@itemize @bullet 49@item 50@cite{How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90, 51C99 and C11 5.1.1.3).} 52 53Diagnostics consist of all the output sent to stderr by GCC@. 54 55@item 56@cite{Whether each nonempty sequence of white-space characters other than 57new-line is retained or replaced by one space character in translation 58phase 3 (C90, C99 and C11 5.1.1.2).} 59 60@xref{Implementation-defined behavior, , Implementation-defined 61behavior, cpp, The C Preprocessor}. 62 63@end itemize 64 65@node Environment implementation 66@section Environment 67 68The behavior of most of these points are dependent on the implementation 69of the C library, and are not defined by GCC itself. 70 71@itemize @bullet 72@item 73@cite{The mapping between physical source file multibyte characters 74and the source character set in translation phase 1 (C90, C99 and C11 755.1.1.2).} 76 77@xref{Implementation-defined behavior, , Implementation-defined 78behavior, cpp, The C Preprocessor}. 79 80@end itemize 81 82@node Identifiers implementation 83@section Identifiers 84 85@itemize @bullet 86@item 87@cite{Which additional multibyte characters may appear in identifiers 88and their correspondence to universal character names (C99 and C11 6.4.2).} 89 90@xref{Implementation-defined behavior, , Implementation-defined 91behavior, cpp, The C Preprocessor}. 92 93@item 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).} 96 97For internal names, all characters are significant. For external names, 98the number of significant characters are defined by the linker; for 99almost all targets, all characters are significant. 100 101@item 102@cite{Whether case distinctions are significant in an identifier with 103external linkage (C90 6.1.2).} 104 105This is a property of the linker. C99 and C11 require that case distinctions 106are always significant in identifiers with external linkage and 107systems without this property are not supported by GCC@. 108 109@end itemize 110 111@node Characters implementation 112@section Characters 113 114@itemize @bullet 115@item 116@cite{The number of bits in a byte (C90 3.4, C99 and C11 3.6).} 117 118Determined by ABI@. 119 120@item 121@cite{The values of the members of the execution character set (C90, 122C99 and C11 5.2.1).} 123 124Determined by ABI@. 125 126@item 127@cite{The unique value of the member of the execution character set produced 128for each of the standard alphabetic escape sequences (C90, C99 and C11 1295.2.2).} 130 131Determined by ABI@. 132 133@item 134@cite{The value of a @code{char} object into which has been stored any 135character other than a member of the basic execution character set 136(C90 6.1.2.5, C99 and C11 6.2.5).} 137 138Determined by ABI@. 139 140@item 141@cite{Which of @code{signed char} or @code{unsigned char} has the same 142range, representation, and behavior as ``plain'' @code{char} (C90 1436.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1).} 144 145@opindex fsigned-char 146@opindex funsigned-char 147Determined by ABI@. The options @option{-funsigned-char} and 148@option{-fsigned-char} change the default. @xref{C Dialect Options, , 149Options Controlling C Dialect}. 150 151@item 152@cite{The mapping of members of the source character set (in character 153constants and string literals) to members of the execution character 154set (C90 6.1.3.4, C99 and C11 6.4.4.4, C90, C99 and C11 5.1.1.2).} 155 156Determined by ABI@. 157 158@item 159@cite{The value of an integer character constant containing more than one 160character or containing a character or escape sequence that does not map 161to a single-byte execution character (C90 6.1.3.4, C99 and C11 6.4.4.4).} 162 163@xref{Implementation-defined behavior, , Implementation-defined 164behavior, cpp, The C Preprocessor}. 165 166@item 167@cite{The value of a wide character constant containing more than one 168multibyte character or a single multibyte character that maps to 169multiple members of the extended execution character set, or 170containing a multibyte character or escape sequence not represented in 171the extended execution character set (C90 6.1.3.4, C99 and C11 1726.4.4.4).} 173 174@xref{Implementation-defined behavior, , Implementation-defined 175behavior, cpp, The C Preprocessor}. 176 177@item 178@cite{The current locale used to convert a wide character constant consisting 179of a single multibyte character that maps to a member of the extended 180execution character set into a corresponding wide character code (C90 1816.1.3.4, C99 and C11 6.4.4.4).} 182 183@xref{Implementation-defined behavior, , Implementation-defined 184behavior, cpp, The C Preprocessor}. 185 186@item 187@cite{Whether differently-prefixed wide string literal tokens can be 188concatenated and, if so, the treatment of the resulting multibyte 189character sequence (C11 6.4.5).} 190 191Such tokens may not be concatenated. 192 193@item 194@cite{The current locale used to convert a wide string literal into 195corresponding wide character codes (C90 6.1.4, C99 and C11 6.4.5).} 196 197@xref{Implementation-defined behavior, , Implementation-defined 198behavior, cpp, The C Preprocessor}. 199 200@item 201@cite{The value of a string literal containing a multibyte character or escape 202sequence not represented in the execution character set (C90 6.1.4, 203C99 and C11 6.4.5).} 204 205@xref{Implementation-defined behavior, , Implementation-defined 206behavior, cpp, The C Preprocessor}. 207 208@item 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).} 213 214@xref{Implementation-defined behavior, , Implementation-defined 215behavior, cpp, The C Preprocessor}. @code{char16_t} and 216@code{char32_t} literals are always encoded in UTF-16 and UTF-32 217respectively. 218 219@end itemize 220 221@node Integers implementation 222@section Integers 223 224@itemize @bullet 225@item 226@cite{Any extended integer types that exist in the implementation (C99 227and C11 6.2.5).} 228 229GCC 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. 236 237@item 238@cite{Whether signed integer types are represented using sign and magnitude, 239two's complement, or one's complement, and whether the extraordinary value 240is a trap representation or an ordinary value (C99 and C11 6.2.6.2).} 241 242GCC supports only two's complement integer types, and all bit patterns 243are ordinary values. 244 245@item 246@cite{The rank of any extended integer type relative to another extended 247integer type with the same precision (C99 and C11 6.3.1.1).} 248 249GCC does not support any extended integer types. 250@c If it did, there would only be one of each precision and signedness. 251 252@item 253@cite{The result of, or the signal raised by, converting an integer to a 254signed integer type when the value cannot be represented in an object of 255that type (C90 6.2.1.2, C99 and C11 6.3.1.3).} 256 257For conversion to a type of width @math{N}, the value is reduced 258modulo @math{2^N} to be within range of the type; no signal is raised. 259 260@item 261@cite{The results of some bitwise operations on signed integers (C90 2626.3, C99 and C11 6.5).} 263 264Bitwise operators act on the representation of the value including 265both the sign and value bits, where the sign bit is considered 266immediately above the highest-value value bit. Signed @samp{>>} acts 267on negative numbers by sign extension. 268 269As an extension to the C language, GCC does not use the latitude given in 270C99 and C11 only to treat certain aspects of signed @samp{<<} as undefined. 271However, @option{-fsanitize=shift} (and @option{-fsanitize=undefined}) will 272diagnose such cases. They are also diagnosed where constant 273expressions are required. 274 275@item 276@cite{The sign of the remainder on integer division (C90 6.3.5).} 277 278GCC always follows the C99 and C11 requirement that the result of division is 279truncated towards zero. 280 281@end itemize 282 283@node Floating point implementation 284@section Floating Point 285 286@itemize @bullet 287@item 288@cite{The accuracy of the floating-point operations and of the library 289functions in @code{<math.h>} and @code{<complex.h>} that return floating-point 290results (C90, C99 and C11 5.2.4.2.2).} 291 292The accuracy is unknown. 293 294@item 295@cite{The rounding behaviors characterized by non-standard values 296of @code{FLT_ROUNDS} @gol 297(C90, C99 and C11 5.2.4.2.2).} 298 299GCC does not use such values. 300 301@item 302@cite{The evaluation methods characterized by non-standard negative 303values of @code{FLT_EVAL_METHOD} (C99 and C11 5.2.4.2.2).} 304 305GCC does not use such values. 306 307@item 308@cite{The direction of rounding when an integer is converted to a 309floating-point number that cannot exactly represent the original 310value (C90 6.2.1.3, C99 and C11 6.3.1.4).} 311 312C99 Annex F is followed. 313 314@item 315@cite{The direction of rounding when a floating-point number is 316converted to a narrower floating-point number (C90 6.2.1.4, C99 and C11 3176.3.1.5).} 318 319C99 Annex F is followed. 320 321@item 322@cite{How the nearest representable value or the larger or smaller 323representable value immediately adjacent to the nearest representable 324value is chosen for certain floating constants (C90 6.1.3.1, C99 and C11 3256.4.4.2).} 326 327C99 Annex F is followed. 328 329@item 330@cite{Whether and how floating expressions are contracted when not 331disallowed by the @code{FP_CONTRACT} pragma (C99 and C11 6.5).} 332 333Expressions are currently only contracted if @option{-ffp-contract=fast}, 334@option{-funsafe-math-optimizations} or @option{-ffast-math} are used. 335This is subject to change. 336 337@item 338@cite{The default state for the @code{FENV_ACCESS} pragma (C99 and C11 3397.6.1).} 340 341This pragma is not implemented, but the default is to ``off'' unless 342@option{-frounding-math} is used in which case it is ``on''. 343 344@item 345@cite{Additional floating-point exceptions, rounding modes, environments, 346and classifications, and their macro names (C99 and C11 7.6, C99 and 347C11 7.12).} 348 349This is dependent on the implementation of the C library, and is not 350defined by GCC itself. 351 352@item 353@cite{The default state for the @code{FP_CONTRACT} pragma (C99 and C11 3547.12.2).} 355 356This pragma is not implemented. Expressions are currently only 357contracted if @option{-ffp-contract=fast}, 358@option{-funsafe-math-optimizations} or @option{-ffast-math} are used. 359This is subject to change. 360 361@item 362@cite{Whether the ``inexact'' floating-point exception can be raised 363when the rounded result actually does equal the mathematical result 364in an IEC 60559 conformant implementation (C99 F.9).} 365 366This is dependent on the implementation of the C library, and is not 367defined by GCC itself. 368 369@item 370@cite{Whether the ``underflow'' (and ``inexact'') floating-point 371exception can be raised when a result is tiny but not inexact in an 372IEC 60559 conformant implementation (C99 F.9).} 373 374This is dependent on the implementation of the C library, and is not 375defined by GCC itself. 376 377@end itemize 378 379@node Arrays and pointers implementation 380@section Arrays and Pointers 381 382@itemize @bullet 383@item 384@cite{The result of converting a pointer to an integer or 385vice versa (C90 6.3.4, C99 and C11 6.3.2.3).} 386 387A cast from pointer to integer discards most-significant bits if the 388pointer representation is larger than the integer type, 389sign-extends@footnote{Future versions of GCC may zero-extend, or use 390a target-defined @code{ptr_extend} pattern. Do not rely on sign extension.} 391if the pointer representation is smaller than the integer type, otherwise 392the 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. 398 399A cast from integer to pointer discards most-significant bits if the 400pointer representation is smaller than the integer type, extends according 401to the signedness of the integer type if the pointer representation 402is larger than the integer type, otherwise the bits are unchanged. 403 404When casting from pointer to integer and back again, the resulting 405pointer must reference the same object as the original pointer, otherwise 406the behavior is undefined. That is, one may not use integer arithmetic to 407avoid the undefined behavior of pointer arithmetic as proscribed in 408C99 and C11 6.5.6/8. 409 410@item 411@cite{The size of the result of subtracting two pointers to elements 412of the same array (C90 6.3.6, C99 and C11 6.5.6).} 413 414The value is as specified in the standard and the type is determined 415by the ABI@. 416 417@end itemize 418 419@node Hints implementation 420@section Hints 421 422@itemize @bullet 423@item 424@cite{The extent to which suggestions made by using the @code{register} 425storage-class specifier are effective (C90 6.5.1, C99 and C11 6.7.1).} 426 427The @code{register} specifier affects code generation only in these ways: 428 429@itemize @bullet 430@item 431When used as part of the register variable extension, see 432@ref{Explicit Register Variables}. 433 434@item 435When @option{-O0} is in use, the compiler allocates distinct stack 436memory for all variables that do not have the @code{register} 437storage-class specifier; if @code{register} is specified, the variable 438may have a shorter lifespan than the code would indicate and may never 439be placed in memory. 440 441@item 442On some rare x86 targets, @code{setjmp} doesn't save the registers in 443all circumstances. In those cases, GCC doesn't allocate any variables 444in registers unless they are marked @code{register}. 445 446@end itemize 447 448@item 449@cite{The extent to which suggestions made by using the inline function 450specifier are effective (C99 and C11 6.7.4).} 451 452GCC will not inline any functions if the @option{-fno-inline} option is 453used or if @option{-O0} is used. Otherwise, GCC may still be unable to 454inline a function for many reasons; the @option{-Winline} option may be 455used to determine if a function has not been inlined and why not. 456 457@end itemize 458 459@node Structures unions enumerations and bit-fields implementation 460@section Structures, Unions, Enumerations, and Bit-Fields 461 462@itemize @bullet 463@item 464@cite{A member of a union object is accessed using a member of a 465different type (C90 6.3.2.3).} 466 467The relevant bytes of the representation of the object are treated as 468an object of the type used for the access. @xref{Type-punning}. This 469may be a trap representation. 470 471@item 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).} 475 476@opindex funsigned-bitfields 477By default it is treated as @code{signed int} but this may be changed 478by the @option{-funsigned-bitfields} option. 479 480@item 481@cite{Allowable bit-field types other than @code{_Bool}, @code{signed int}, 482and @code{unsigned int} (C99 and C11 6.7.2.1).} 483 484Other integer types, such as @code{long int}, and enumerated types are 485permitted even in strictly conforming mode. 486 487@item 488@cite{Whether atomic types are permitted for bit-fields (C11 6.7.2.1).} 489 490Atomic types are not permitted for bit-fields. 491 492@item 493@cite{Whether a bit-field can straddle a storage-unit boundary (C90 4946.5.2.1, C99 and C11 6.7.2.1).} 495 496Determined by ABI@. 497 498@item 499@cite{The order of allocation of bit-fields within a unit (C90 5006.5.2.1, C99 and C11 6.7.2.1).} 501 502Determined by ABI@. 503 504@item 505@cite{The alignment of non-bit-field members of structures (C90 5066.5.2.1, C99 and C11 6.7.2.1).} 507 508Determined by ABI@. 509 510@item 511@cite{The integer type compatible with each enumerated type (C90 5126.5.2.2, C99 and C11 6.7.2.2).} 513 514@opindex fshort-enums 515Normally, the type is @code{unsigned int} if there are no negative 516values in the enumeration, otherwise @code{int}. If 517@option{-fshort-enums} is specified, then if there are negative values 518it is the first of @code{signed char}, @code{short} and @code{int} 519that can represent all the values, otherwise it is the first of 520@code{unsigned char}, @code{unsigned short} and @code{unsigned int} 521that 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. 528 529On some targets, @option{-fshort-enums} is the default; this is 530determined by the ABI@. 531 532@end itemize 533 534@node Qualifiers implementation 535@section Qualifiers 536 537@itemize @bullet 538@item 539@cite{What constitutes an access to an object that has volatile-qualified 540type (C90 6.5.3, C99 and C11 6.7.3).} 541 542Such an object is normally accessed by pointers and used for accessing 543hardware. In most expressions, it is intuitively obvious what is a read 544and what is a write. For example 545 546@smallexample 547volatile int *dst = @var{somevalue}; 548volatile int *src = @var{someothervalue}; 549*dst = *src; 550@end smallexample 551 552@noindent 553will cause a read of the volatile object pointed to by @var{src} and store the 554value into the volatile object pointed to by @var{dst}. There is no 555guarantee that these reads and writes are atomic, especially for objects 556larger than @code{int}. 557 558However, if the volatile storage is not being modified, and the value of 559the volatile storage is not used, then the situation is less obvious. 560For example 561 562@smallexample 563volatile int *src = @var{somevalue}; 564*src; 565@end smallexample 566 567According to the C standard, such an expression is an rvalue whose type 568is the unqualified version of its original type, i.e.@: @code{int}. Whether 569GCC interprets this as a read of the volatile object being pointed to or 570only as a request to evaluate the expression for its side effects depends 571on this type. 572 573If it is a scalar type, or on most targets an aggregate type whose only 574member object is of a scalar type, or a union type whose member objects 575are of scalar types, the expression is interpreted by GCC as a read of 576the volatile object; in the other cases, the expression is only evaluated 577for its side effects. 578 579When an object of an aggregate type, with the same size and alignment as a 580scalar type @code{S}, is the subject of a volatile access by an assignment 581expression or an atomic function, the access to it is performed as if the 582object's declared type were @code{volatile S}. 583 584@end itemize 585 586@node Declarators implementation 587@section Declarators 588 589@itemize @bullet 590@item 591@cite{The maximum number of declarators that may modify an arithmetic, 592structure or union type (C90 6.5.4).} 593 594GCC is only limited by available memory. 595 596@end itemize 597 598@node Statements implementation 599@section Statements 600 601@itemize @bullet 602@item 603@cite{The maximum number of @code{case} values in a @code{switch} 604statement (C90 6.6.4.2).} 605 606GCC is only limited by available memory. 607 608@end itemize 609 610@node Preprocessing directives implementation 611@section Preprocessing Directives 612 613@xref{Implementation-defined behavior, , Implementation-defined 614behavior, cpp, The C Preprocessor}, for details of these aspects of 615implementation-defined behavior. 616 617@itemize @bullet 618@item 619@cite{The locations within @code{#pragma} directives where header name 620preprocessing tokens are recognized (C11 6.4, C11 6.4.7).} 621 622@item 623@cite{How sequences in both forms of header names are mapped to headers 624or external source file names (C90 6.1.7, C99 and C11 6.4.7).} 625 626@item 627@cite{Whether the value of a character constant in a constant expression 628that controls conditional inclusion matches the value of the same character 629constant in the execution character set (C90 6.8.1, C99 and C11 6.10.1).} 630 631@item 632@cite{Whether the value of a single-character character constant in a 633constant expression that controls conditional inclusion may have a 634negative value (C90 6.8.1, C99 and C11 6.10.1).} 635 636@item 637@cite{The places that are searched for an included @samp{<>} delimited 638header, and how the places are specified or the header is 639identified (C90 6.8.2, C99 and C11 6.10.2).} 640 641@item 642@cite{How the named source file is searched for in an included @samp{""} 643delimited header (C90 6.8.2, C99 and C11 6.10.2).} 644 645@item 646@cite{The method by which preprocessing tokens (possibly resulting from 647macro expansion) in a @code{#include} directive are combined into a header 648name (C90 6.8.2, C99 and C11 6.10.2).} 649 650@item 651@cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99 652and C11 6.10.2).} 653 654@item 655@cite{Whether the @samp{#} operator inserts a @samp{\} character before 656the @samp{\} character that begins a universal character name in a 657character constant or string literal (C99 and C11 6.10.3.2).} 658 659@item 660@cite{The behavior on each recognized non-@code{STDC #pragma} 661directive (C90 6.8.6, C99 and C11 6.10.6).} 662 663@xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of 664pragmas accepted by GCC on all targets. @xref{Pragmas, , Pragmas 665Accepted by GCC}, for details of target-specific pragmas. 666 667@item 668@cite{The definitions for @code{__DATE__} and @code{__TIME__} when 669respectively, the date and time of translation are not available (C90 6706.8.8, C99 6.10.8, C11 6.10.8.1).} 671 672@end itemize 673 674@node Library functions implementation 675@section Library Functions 676 677The behavior of most of these points are dependent on the implementation 678of the C library, and are not defined by GCC itself. 679 680@itemize @bullet 681@item 682@cite{The null pointer constant to which the macro @code{NULL} expands 683(C90 7.1.6, C99 7.17, C11 7.19).} 684 685In @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}. GCC 686does not provide the other headers which define @code{NULL} and some 687library implementations may use other definitions in those headers. 688 689@end itemize 690 691@node Architecture implementation 692@section Architecture 693 694@itemize @bullet 695@item 696@cite{The values or expressions assigned to the macros specified in the 697headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>} 698(C90, C99 and C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11 7.20.2, C11 7.20.3).} 699 700Determined by ABI@. 701 702@item 703@cite{The result of attempting to indirectly access an object with 704automatic or thread storage duration from a thread other than the one 705with which it is associated (C11 6.2.4).} 706 707Such accesses are supported, subject to the same requirements for 708synchronization for concurrent accesses as for concurrent accesses to 709any object. 710 711@item 712@cite{The number, order, and encoding of bytes in any object 713(when not explicitly specified in this International Standard) (C99 714and C11 6.2.6.1).} 715 716Determined by ABI@. 717 718@item 719@cite{Whether any extended alignments are supported and the contexts 720in which they are supported (C11 6.2.8).} 721 722Extended alignments up to @math{2^{28}} (bytes) are supported for 723objects of automatic storage duration. Alignments supported for 724objects of static and thread storage duration are determined by the 725ABI. 726 727@item 728@cite{Valid alignment values other than those returned by an _Alignof 729expression for fundamental types, if any (C11 6.2.8).} 730 731Valid alignments are powers of 2 up to and including @math{2^{28}}. 732 733@item 734@cite{The value of the result of the @code{sizeof} and @code{_Alignof} 735operators (C90 6.3.3.4, C99 and C11 6.5.3.4).} 736 737Determined by ABI@. 738 739@end itemize 740 741@node Locale-specific behavior implementation 742@section Locale-Specific Behavior 743 744The behavior of these points are dependent on the implementation 745of the C library, and are not defined by GCC itself. 746