* Typeof:: @code{typeof}: referring to the type of an expression.
* Conditionals:: Omitting the middle operand of a @samp{?:} expression.
* Additional Numeric Types:: Additional sizes and formats, plus complex numbers.
+* Aggregate Types:: Extensions to arrays, structs, and unions.
* Hex Floats:: Hexadecimal floating-point constants.
* Named Address Spaces::Named address spaces.
-* Zero Length:: Zero-length arrays.
-* Empty Structures:: Structures with no members.
-* Flexible Array Members in Unions:: Unions with Flexible Array Members.
-* Flexible Array Members alone in Structures:: Structures with only Flexible Array Members.
-* Variable Length:: Arrays whose length is computed at run time.
* Variadic Macros:: Macros with a variable number of arguments.
* Escaped Newlines:: Slightly looser rules for escaped newlines.
-* Subscripting:: Any array can be subscripted, even if not an lvalue.
* Pointer Arith:: Arithmetic on @code{void}-pointers and function pointers.
* Variadic Pointer Args:: Pointer arguments to variadic functions.
* Pointers to Arrays:: Pointers to arrays with qualifiers work as expected.
-* Initializers:: Non-constant initializers.
-* Compound Literals:: Compound literals give structures, unions
- or arrays as values.
-* Designated Inits:: Labeling elements of initializers.
* Case Ranges:: `case 1 ... 9' and such.
-* Cast to Union:: Casting to union type from any member of the union.
* Mixed Labels and Declarations:: Mixing declarations, labels and code.
* Function Attributes:: Declaring that functions have no side effects,
or that they can never return.
* Target Builtins:: Built-in functions specific to particular targets.
* Target Format Checks:: Format checks specific to particular targets.
* Pragmas:: Pragmas accepted by GCC.
-* Unnamed Fields:: Unnamed struct/union fields within structs/unions.
* Thread-Local:: Per-thread variables.
* Binary constants:: Binary constants using the @samp{0b} prefix.
* OpenMP:: Multiprocessing extensions.
Fixed-point types are supported by the DWARF debug information format.
-@node Hex Floats
-@section Hex Floats
-@cindex hex floats
-
-ISO C99 and ISO C++17 support floating-point numbers written not only in
-the usual decimal notation, such as @code{1.55e1}, but also numbers such as
-@code{0x1.fp3} written in hexadecimal format. As a GNU extension, GCC
-supports this in C90 mode (except in some cases when strictly
-conforming) and in C++98, C++11 and C++14 modes. In that format the
-@samp{0x} hex introducer and the @samp{p} or @samp{P} exponent field are
-mandatory. The exponent is a decimal number that indicates the power of
-2 by which the significant part is multiplied. Thus @samp{0x1.f} is
-@tex
-$1 {15\over16}$,
-@end tex
-@ifnottex
-1 15/16,
-@end ifnottex
-@samp{p3} multiplies it by 8, and the value of @code{0x1.fp3}
-is the same as @code{1.55e1}.
-
-Unlike for floating-point numbers in the decimal notation the exponent
-is always required in the hexadecimal notation. Otherwise the compiler
-would not be able to resolve the ambiguity of, e.g., @code{0x1.f}. This
-could mean @code{1.0f} or @code{1.9375} since @samp{f} is also the
-extension for floating-point constants of type @code{float}.
-
-@node Named Address Spaces
-@section Named Address Spaces
-@cindex Named Address Spaces
-
-As an extension, GNU C supports named address spaces as
-defined in the N1275 draft of ISO/IEC DTR 18037. Support for named
-address spaces in GCC will evolve as the draft technical report
-changes. Calling conventions for any target might also change. At
-present, only the AVR, M32C, PRU, RL78, and x86 targets support
-address spaces other than the generic address space.
-
-Address space identifiers may be used exactly like any other C type
-qualifier (e.g., @code{const} or @code{volatile}). See the N1275
-document for more details.
-
-@anchor{AVR Named Address Spaces}
-@subsection AVR Named Address Spaces
-
-On the AVR target, there are several address spaces that can be used
-in order to put read-only data into the flash memory and access that
-data by means of the special instructions @code{LPM} or @code{ELPM}
-needed to read from flash.
-
-Devices belonging to @code{avrtiny} and @code{avrxmega3} can access
-flash memory by means of @code{LD*} instructions because the flash
-memory is mapped into the RAM address space. There is @emph{no need}
-for language extensions like @code{__flash} or attribute
-@ref{AVR Variable Attributes,,@code{progmem}}.
-The default linker description files for these devices cater for that
-feature and @code{.rodata} stays in flash: The compiler just generates
-@code{LD*} instructions, and the linker script adds core specific
-offsets to all @code{.rodata} symbols: @code{0x4000} in the case of
-@code{avrtiny} and @code{0x8000} in the case of @code{avrxmega3}.
-See @ref{AVR Options} for a list of respective devices.
-
-For devices not in @code{avrtiny} or @code{avrxmega3},
-any data including read-only data is located in RAM (the generic
-address space) because flash memory is not visible in the RAM address
-space. In order to locate read-only data in flash memory @emph{and}
-to generate the right instructions to access this data without
-using (inline) assembler code, special address spaces are needed.
-
-@table @code
-@cindex @code{__flash} AVR Named Address Spaces
-@item __flash
-The @code{__flash} qualifier locates data in the
-@code{.progmem.data} section. Data is read using the @code{LPM}
-instruction. Pointers to this address space are 16 bits wide.
-
-@cindex @code{__flash1} AVR Named Address Spaces
-@cindex @code{__flash2} AVR Named Address Spaces
-@cindex @code{__flash3} AVR Named Address Spaces
-@cindex @code{__flash4} AVR Named Address Spaces
-@cindex @code{__flash5} AVR Named Address Spaces
-@item __flash1
-@itemx __flash2
-@itemx __flash3
-@itemx __flash4
-@itemx __flash5
-These are 16-bit address spaces locating data in section
-@code{.progmem@var{N}.data} where @var{N} refers to
-address space @code{__flash@var{N}}.
-The compiler sets the @code{RAMPZ} segment register appropriately
-before reading data by means of the @code{ELPM} instruction.
-
-@cindex @code{__flashx} AVR Named Address Spaces
-@item __flashx
+@node Aggregate Types
+@section Array, Union, and Struct Extensions
-This is a 24-bit flash address space locating data in section
-@code{.progmemx.data}.
-The compiler sets the @code{RAMPZ} segment register appropriately
-before reading data by means of the @code{ELPM} instruction.
+GCC supports several extensions relating to array, union, and struct types,
+including extensions for aggregate initializers for objects of these types.
-@cindex @code{__memx} AVR Named Address Spaces
-@item __memx
-This is a 24-bit address space that linearizes flash and RAM:
-If the high bit of the address is set, data is read from
-RAM using the lower two bytes as RAM address.
-If the high bit of the address is clear, data is read from flash
-with @code{RAMPZ} set according to the high byte of the address.
-@xref{AVR Built-in Functions,,@code{__builtin_avr_flash_segment}}.
+@menu
+* Variable Length:: Arrays whose length is computed at run time.
+* Zero Length:: Zero-length arrays.
+* Empty Structures:: Structures with no members.
+* Flexible Array Members in Unions:: Unions with Flexible Array Members.
+* Flexible Array Members alone in Structures:: Structures with only Flexible Array Members.
+* Unnamed Fields:: Unnamed struct/union fields within structs/unions.
+* Cast to Union:: Casting to union type from any member of the union.
+* Subscripting:: Any array can be subscripted, even if not an lvalue.
+* Initializers:: Non-constant initializers.
+* Compound Literals:: Compound literals give structures, unions
+ or arrays as values.
+* Designated Inits:: Labeling elements of initializers.
+@end menu
-Objects in this address space are located in @code{.progmemx.data}.
-@end table
+@node Variable Length
+@subsection Arrays of Variable Length
+@cindex variable-length arrays
+@cindex arrays of variable length
+@cindex VLAs
-@b{Example}
+Variable-length automatic arrays are allowed in ISO C99, and as an
+extension GCC accepts them in C90 mode and in C++. These arrays are
+declared like any other automatic arrays, but with a length that is not
+a constant expression. The storage is allocated at the point of
+declaration and deallocated when the block scope containing the declaration
+exits. For
+example:
@smallexample
-char my_read (const __flash char ** p)
+FILE *
+concat_fopen (char *s1, char *s2, char *mode)
@{
- /* p is a pointer to RAM that points to a pointer to flash.
- The first indirection of p reads that flash pointer
- from RAM and the second indirection reads a char from this
- flash address. */
-
- return **p;
+ char str[strlen (s1) + strlen (s2) + 1];
+ strcpy (str, s1);
+ strcat (str, s2);
+ return fopen (str, mode);
@}
+@end smallexample
-/* Locate array[] in flash memory */
-const __flash int array[] = @{ 3, 5, 7, 11, 13, 17, 19 @};
+@cindex scope of a variable length array
+@cindex variable-length array scope
+@cindex deallocating variable length arrays
+Jumping or breaking out of the scope of the array name deallocates the
+storage. Jumping into the scope is not allowed; you get an error
+message for it.
-int i = 1;
+@cindex variable-length array in a structure
+As an extension, GCC accepts variable-length arrays as a member of
+a structure or a union. For example:
-int main (void)
+@smallexample
+void
+foo (int n)
@{
- /* Return 17 by reading from flash memory */
- return array[array[i]];
+ struct S @{ int x[n]; @};
@}
@end smallexample
-@noindent
-For each named address space supported by avr-gcc there is an equally
-named but uppercase built-in macro defined.
-The purpose is to facilitate testing if respective address space
-support is available or not:
+@cindex @code{alloca} vs variable-length arrays
+You can use the function @code{alloca} to get an effect much like
+variable-length arrays. The function @code{alloca} is available in
+many other C implementations (but not in all). On the other hand,
+variable-length arrays are more elegant.
-@smallexample
-#ifdef __FLASH
-const __flash int var = 1;
+There are other differences between these two methods. Space allocated
+with @code{alloca} exists until the containing @emph{function} returns.
+The space for a variable-length array is deallocated as soon as the array
+name's scope ends, unless you also use @code{alloca} in this scope.
-int read_var (void)
+You can also use variable-length arrays as arguments to functions:
+
+@smallexample
+struct entry
+tester (int len, char data[len][len])
@{
- return var;
+ /* @r{@dots{}} */
@}
-#else
-#include <avr/pgmspace.h> /* From AVR-LibC */
+@end smallexample
-const int var PROGMEM = 1;
+The length of an array is computed once when the storage is allocated
+and is remembered for the scope of the array in case you access it with
+@code{sizeof}.
-int read_var (void)
+If you want to pass the array first and the length afterward, you can
+use a forward declaration in the parameter list---another GNU extension.
+
+@smallexample
+struct entry
+tester (int len; char data[len][len], int len)
@{
- return (int) pgm_read_word (&var);
+ /* @r{@dots{}} */
@}
-#endif /* __FLASH */
@end smallexample
-@noindent
-Notice that attribute @ref{AVR Variable Attributes,,@code{progmem}}
-locates data in flash but
-accesses to these data read from generic address space, i.e.@:
-from RAM,
-so that you need special accessors like @code{pgm_read_byte}
-from @w{@uref{https://avrdudes.github.io/avr-libc/avr-libc-user-manual/,AVR-LibC}}
-together with attribute @code{progmem}.
+@cindex parameter forward declaration
+The @samp{int len} before the semicolon is a @dfn{parameter forward
+declaration}, and it serves the purpose of making the name @code{len}
+known when the declaration of @code{data} is parsed.
-@noindent
-@b{Limitations and Caveats}
+You can write any number of such parameter forward declarations in the
+parameter list. They can be separated by commas or semicolons, but the
+last one must end with a semicolon, which is followed by the ``real''
+parameter declarations. Each forward declaration must match a ``real''
+declaration in parameter name and data type. ISO C99 does not support
+parameter forward declarations.
-@itemize
-@item
-Reading across the 64@tie{}KiB section boundary of
-the @code{__flash} or @code{__flash@var{N}} address spaces
-is not supported. The only address spaces that
-support reading across the 64@tie{}KiB flash segment boundaries are
-@code{__memx} and @code{__flashx}.
-
-@item
-If you use one of the @code{__flash@var{N}} address spaces
-you must arrange your linker script to locate the
-@code{.progmem@var{N}.data} sections according to your needs.
-For an example, see the
-@w{@uref{https://gcc.gnu.org/wiki/avr-gcc#Address_Spaces,avr-gcc wiki}}
-
-@item
-Any data or pointers to the non-generic address spaces must
-be qualified as @code{const}, i.e.@: as read-only data.
-This still applies if the data in one of these address
-spaces like software version number or calibration lookup table are intended to
-be changed after load time by, say, a boot loader. In this case
-the right qualification is @code{const} @code{volatile} so that the compiler
-must not optimize away known values or insert them
-as immediates into operands of instructions.
-
-@item
-The following code initializes a variable @code{pfoo}
-located in static storage with a 24-bit address:
-@smallexample
-extern const __memx char foo;
-const __memx void *pfoo = &foo;
-@end smallexample
-
-@item
-On the reduced Tiny devices like ATtiny40, no address spaces are supported.
-Just use vanilla C / C++ code without overhead as outlined above.
-Attribute @code{progmem} is supported but works differently,
-see @ref{AVR Variable Attributes}.
-
-@end itemize
-
-@subsection M32C Named Address Spaces
-@cindex @code{__far} M32C Named Address Spaces
-
-On the M32C target, with the R8C and M16C CPU variants, variables
-qualified with @code{__far} are accessed using 32-bit addresses in
-order to access memory beyond the first 64@tie{}Ki bytes. If
-@code{__far} is used with the M32CM or M32C CPU variants, it has no
-effect.
-
-@subsection PRU Named Address Spaces
-@cindex @code{__regio_symbol} PRU Named Address Spaces
-
-On the PRU target, variables qualified with @code{__regio_symbol} are
-aliases used to access the special I/O CPU registers. They must be
-declared as @code{extern} because such variables will not be allocated in
-any data memory. They must also be marked as @code{volatile}, and can
-only be 32-bit integer types. The only names those variables can have
-are @code{__R30} and @code{__R31}, representing respectively the
-@code{R30} and @code{R31} special I/O CPU registers. Hence the following
-example is the only valid usage of @code{__regio_symbol}:
-
-@smallexample
-extern volatile __regio_symbol uint32_t __R30;
-extern volatile __regio_symbol uint32_t __R31;
-@end smallexample
-
-@subsection RL78 Named Address Spaces
-@cindex @code{__far} RL78 Named Address Spaces
-
-On the RL78 target, variables qualified with @code{__far} are accessed
-with 32-bit pointers (20-bit addresses) rather than the default 16-bit
-addresses. Non-far variables are assumed to appear in the topmost
-64@tie{}KiB of the address space.
-
-@subsection x86 Named Address Spaces
-@cindex x86 named address spaces
-
-On the x86 target, variables may be declared as being relative
-to the @code{%fs} or @code{%gs} segments.
-
-@table @code
-@cindex @code{__seg_fs} x86 named address space
-@cindex @code{__seg_gs} x86 named address space
-@item __seg_fs
-@itemx __seg_gs
-The object is accessed with the respective segment override prefix.
-
-The respective segment base must be set via some method specific to
-the operating system. Rather than require an expensive system call
-to retrieve the segment base, these address spaces are not considered
-to be subspaces of the generic (flat) address space. This means that
-explicit casts are required to convert pointers between these address
-spaces and the generic address space. In practice the application
-should cast to @code{uintptr_t} and apply the segment base offset
-that it installed previously.
-
-The preprocessor symbols @code{__SEG_FS} and @code{__SEG_GS} are
-defined when these address spaces are supported.
-@end table
-
-@node Zero Length
-@section Arrays of Length Zero
-@cindex arrays of length zero
-@cindex zero-length arrays
-@cindex length-zero arrays
-@cindex flexible array members
+@node Zero Length
+@subsection Arrays of Length Zero
+@cindex arrays of length zero
+@cindex zero-length arrays
+@cindex length-zero arrays
+@cindex flexible array members
Declaring zero-length arrays is allowed in GNU C as an extension.
A zero-length array can be useful as the last element of a structure
@end smallexample
@node Empty Structures
-@section Structures with No Members
+@subsection Structures with No Members
@cindex empty structures
@cindex zero-size structures
member of type @code{char}.
@node Flexible Array Members in Unions
-@section Unions with Flexible Array Members
+@subsection Unions with Flexible Array Members
@cindex unions with flexible array members
@cindex unions with FAMs
such a union is zero.
@node Flexible Array Members alone in Structures
-@section Structures with only Flexible Array Members
+@subsection Structures with only Flexible Array Members
@cindex structures with only flexible array members
@cindex structures with only FAMs
The size of such a structure is zero.
-@node Variable Length
-@section Arrays of Variable Length
-@cindex variable-length arrays
-@cindex arrays of variable length
-@cindex VLAs
+@node Unnamed Fields
+@subsection Unnamed Structure and Union Fields
+@cindex @code{struct}
+@cindex @code{union}
-Variable-length automatic arrays are allowed in ISO C99, and as an
-extension GCC accepts them in C90 mode and in C++. These arrays are
-declared like any other automatic arrays, but with a length that is not
-a constant expression. The storage is allocated at the point of
-declaration and deallocated when the block scope containing the declaration
-exits. For
-example:
+As permitted by ISO C11 and for compatibility with other compilers,
+GCC allows you to define
+a structure or union that contains, as fields, structures and unions
+without names. For example:
@smallexample
-FILE *
-concat_fopen (char *s1, char *s2, char *mode)
-@{
- char str[strlen (s1) + strlen (s2) + 1];
- strcpy (str, s1);
- strcat (str, s2);
- return fopen (str, mode);
-@}
+struct @{
+ int a;
+ union @{
+ int b;
+ float c;
+ @};
+ int d;
+@} foo;
@end smallexample
-@cindex scope of a variable length array
-@cindex variable-length array scope
-@cindex deallocating variable length arrays
-Jumping or breaking out of the scope of the array name deallocates the
-storage. Jumping into the scope is not allowed; you get an error
-message for it.
+@noindent
+In this example, you are able to access members of the unnamed
+union with code like @samp{foo.b}. Note that only unnamed structs and
+unions are allowed, you may not have, for example, an unnamed
+@code{int}.
-@cindex variable-length array in a structure
-As an extension, GCC accepts variable-length arrays as a member of
-a structure or a union. For example:
+You must never create such structures that cause ambiguous field definitions.
+For example, in this structure:
@smallexample
-void
-foo (int n)
-@{
- struct S @{ int x[n]; @};
-@}
+struct @{
+ int a;
+ struct @{
+ int a;
+ @};
+@} foo;
@end smallexample
-@cindex @code{alloca} vs variable-length arrays
-You can use the function @code{alloca} to get an effect much like
-variable-length arrays. The function @code{alloca} is available in
-many other C implementations (but not in all). On the other hand,
-variable-length arrays are more elegant.
+@noindent
+it is ambiguous which @code{a} is being referred to with @samp{foo.a}.
+The compiler gives errors for such constructs.
-There are other differences between these two methods. Space allocated
-with @code{alloca} exists until the containing @emph{function} returns.
-The space for a variable-length array is deallocated as soon as the array
-name's scope ends, unless you also use @code{alloca} in this scope.
+@opindex fms-extensions
+Unless @option{-fms-extensions} is used, the unnamed field must be a
+structure or union definition without a tag (for example, @samp{struct
+@{ int a; @};}). If @option{-fms-extensions} is used, the field may
+also be a definition with a tag such as @samp{struct foo @{ int a;
+@};}, a reference to a previously defined structure or union such as
+@samp{struct foo;}, or a reference to a @code{typedef} name for a
+previously defined structure or union type.
-You can also use variable-length arrays as arguments to functions:
+@opindex fplan9-extensions
+The option @option{-fplan9-extensions} enables
+@option{-fms-extensions} as well as two other extensions. First, a
+pointer to a structure is automatically converted to a pointer to an
+anonymous field for assignments and function calls. For example:
@smallexample
-struct entry
-tester (int len, char data[len][len])
-@{
- /* @r{@dots{}} */
-@}
+struct s1 @{ int a; @};
+struct s2 @{ struct s1; @};
+extern void f1 (struct s1 *);
+void f2 (struct s2 *p) @{ f1 (p); @}
@end smallexample
-The length of an array is computed once when the storage is allocated
-and is remembered for the scope of the array in case you access it with
-@code{sizeof}.
+@noindent
+In the call to @code{f1} inside @code{f2}, the pointer @code{p} is
+converted into a pointer to the anonymous field.
-If you want to pass the array first and the length afterward, you can
-use a forward declaration in the parameter list---another GNU extension.
+Second, when the type of an anonymous field is a @code{typedef} for a
+@code{struct} or @code{union}, code may refer to the field using the
+name of the @code{typedef}.
@smallexample
-struct entry
-tester (int len; char data[len][len], int len)
-@{
- /* @r{@dots{}} */
-@}
+typedef struct @{ int a; @} s1;
+struct s2 @{ s1; @};
+s1 f1 (struct s2 *p) @{ return p->s1; @}
@end smallexample
-@cindex parameter forward declaration
-The @samp{int len} before the semicolon is a @dfn{parameter forward
-declaration}, and it serves the purpose of making the name @code{len}
-known when the declaration of @code{data} is parsed.
+These usages are only permitted when they are not ambiguous.
-You can write any number of such parameter forward declarations in the
-parameter list. They can be separated by commas or semicolons, but the
-last one must end with a semicolon, which is followed by the ``real''
-parameter declarations. Each forward declaration must match a ``real''
-declaration in parameter name and data type. ISO C99 does not support
-parameter forward declarations.
+@node Cast to Union
+@subsection Cast to a Union Type
+@cindex cast to a union
+@cindex union, casting to a
-@node Variadic Macros
-@section Macros with a Variable Number of Arguments.
-@cindex variable number of arguments
-@cindex macro with variable arguments
-@cindex rest argument (in macro)
-@cindex variadic macros
+A cast to a union type is a C extension not available in C++. It looks
+just like ordinary casts with the constraint that the type specified is
+a union type. You can specify the type either with the @code{union}
+keyword or with a @code{typedef} name that refers to a union. The result
+of a cast to a union is a temporary rvalue of the union type with a member
+whose type matches that of the operand initialized to the value of
+the operand. The effect of a cast to a union is similar to a compound
+literal except that it yields an rvalue like standard casts do.
+@xref{Compound Literals}.
-In the ISO C standard of 1999, a macro can be declared to accept a
-variable number of arguments much as a function can. The syntax for
-defining the macro is similar to that of a function. Here is an
-example:
+Expressions that may be cast to the union type are those whose type matches
+at least one of the members of the union. Thus, given the following union
+and variables:
@smallexample
-#define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)
+union foo @{ int i; double d; @};
+int x;
+double y;
+union foo z;
@end smallexample
@noindent
-Here @samp{@dots{}} is a @dfn{variable argument}. In the invocation of
-such a macro, it represents the zero or more tokens until the closing
-parenthesis that ends the invocation, including any commas. This set of
-tokens replaces the identifier @code{__VA_ARGS__} in the macro body
-wherever it appears. See the CPP manual for more information.
-
-GCC has long supported variadic macros, and used a different syntax that
-allowed you to give a name to the variable arguments just like any other
-argument. Here is an example:
-
+both @code{x} and @code{y} can be cast to type @code{union foo} and
+the following assignments
@smallexample
-#define debug(format, args...) fprintf (stderr, format, args)
+ z = (union foo) x;
+ z = (union foo) y;
@end smallexample
-
-@noindent
-This is in all ways equivalent to the ISO C example above, but arguably
-more readable and descriptive.
-
-GNU CPP has two further variadic macro extensions, and permits them to
-be used with either of the above forms of macro definition.
-
-In standard C, you are not allowed to leave the variable argument out
-entirely; but you are allowed to pass an empty argument. For example,
-this invocation is invalid in ISO C, because there is no comma after
-the string:
-
+are shorthand equivalents of these
@smallexample
-debug ("A message")
+ z = (union foo) @{ .i = x @};
+ z = (union foo) @{ .d = y @};
@end smallexample
-GNU CPP permits you to completely omit the variable arguments in this
-way. In the above examples, the compiler would complain, though since
-the expansion of the macro still has the extra comma after the format
-string.
+However, @code{(union foo) FLT_MAX;} is not a valid cast because the union
+has no member of type @code{float}.
-To help solve this problem, CPP behaves specially for variable arguments
-used with the token paste operator, @samp{##}. If instead you write
+Using the cast as the right-hand side of an assignment to a variable of
+union type is equivalent to storing in a member of the union with
+the same type
@smallexample
-#define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)
+union foo u;
+/* @r{@dots{}} */
+u = (union foo) x @equiv{} u.i = x
+u = (union foo) y @equiv{} u.d = y
@end smallexample
-@noindent
-and if the variable arguments are omitted or empty, the @samp{##}
-operator causes the preprocessor to remove the comma before it. If you
-do provide some variable arguments in your macro invocation, GNU CPP
-does not complain about the paste operation and instead places the
-variable arguments after the comma. Just like any other pasted macro
-argument, these arguments are not macro expanded.
-
-@node Escaped Newlines
-@section Slightly Looser Rules for Escaped Newlines
-@cindex escaped newlines
-@cindex newlines (escaped)
+You can also use the union cast as a function argument:
-The preprocessor treatment of escaped newlines is more relaxed
-than that specified by the C90 standard, which requires the newline
-to immediately follow a backslash.
-GCC's implementation allows whitespace in the form
-of spaces, horizontal and vertical tabs, and form feeds between the
-backslash and the subsequent newline. The preprocessor issues a
-warning, but treats it as a valid escaped newline and combines the two
-lines to form a single logical line. This works within comments and
-tokens, as well as between tokens. Comments are @emph{not} treated as
-whitespace for the purposes of this relaxation, since they have not
-yet been replaced with spaces.
+@smallexample
+void hack (union foo);
+/* @r{@dots{}} */
+hack ((union foo) x);
+@end smallexample
@node Subscripting
-@section Non-Lvalue Arrays May Have Subscripts
+@subsection Non-Lvalue Arrays May Have Subscripts
@cindex subscripting
@cindex arrays, non-lvalue
@end group
@end smallexample
-@node Pointer Arith
-@section Arithmetic on @code{void}- and Function-Pointers
-@cindex void pointers, arithmetic
-@cindex void, size of pointer to
-@cindex function pointers, arithmetic
-@cindex function, size of pointer to
-
-In GNU C, addition and subtraction operations are supported on pointers to
-@code{void} and on pointers to functions. This is done by treating the
-size of a @code{void} or of a function as 1.
-
-A consequence of this is that @code{sizeof} is also allowed on @code{void}
-and on function types, and returns 1.
-
-@opindex Wpointer-arith
-The option @option{-Wpointer-arith} requests a warning if these extensions
-are used.
-
-@node Variadic Pointer Args
-@section Pointer Arguments in Variadic Functions
-@cindex pointer arguments in variadic functions
-@cindex variadic functions, pointer arguments
-
-Standard C requires that pointer types used with @code{va_arg} in
-functions with variable argument lists either must be compatible with
-that of the actual argument, or that one type must be a pointer to
-@code{void} and the other a pointer to a character type. GNU C
-implements the POSIX XSI extension that additionally permits the use
-of @code{va_arg} with a pointer type to receive arguments of any other
-pointer type.
-
-In particular, in GNU C @samp{va_arg (ap, void *)} can safely be used
-to consume an argument of any pointer type.
-
-@node Pointers to Arrays
-@section Pointers to Arrays with Qualifiers Work as Expected
-@cindex pointers to arrays
-@cindex const qualifier
-
-In GNU C, pointers to arrays with qualifiers work similar to pointers
-to other qualified types. For example, a value of type @code{int (*)[5]}
-can be used to initialize a variable of type @code{const int (*)[5]}.
-These types are incompatible in ISO C because the @code{const} qualifier
-is formally attached to the element type of the array and not the
-array itself.
-
-@smallexample
-extern void
-transpose (int N, int M, double out[M][N], const double in[N][M]);
-double x[3][2];
-double y[2][3];
-@r{@dots{}}
-transpose(3, 2, y, x);
-@end smallexample
-
@node Initializers
-@section Non-Constant Initializers
+@subsection Non-Constant Initializers
@cindex initializers, non-constant
@cindex non-constant initializers
@end smallexample
@node Compound Literals
-@section Compound Literals
+@subsection Compound Literals
@cindex constructor expressions
@cindex initializations in expressions
@cindex structures, constructor expression
compound literals in C++ code.
@node Designated Inits
-@section Designated Initializers
+@subsection Designated Initializers
@cindex initializers with labeled elements
@cindex labeled elements in initializers
@cindex case labels in initializers
struct point p = @{ y: yvalue, x: xvalue @};
@end smallexample
-Omitted fields are implicitly initialized the same as for objects
-that have static storage duration.
+Omitted fields are implicitly initialized the same as for objects
+that have static storage duration.
+
+@cindex designators
+The @samp{[@var{index}]} or @samp{.@var{fieldname}} is known as a
+@dfn{designator}. You can also use a designator (or the obsolete colon
+syntax) when initializing a union, to specify which element of the union
+should be used. For example,
+
+@smallexample
+union foo @{ int i; double d; @};
+
+union foo f = @{ .d = 4 @};
+@end smallexample
+
+@noindent
+converts 4 to a @code{double} to store it in the union using
+the second element. By contrast, casting 4 to type @code{union foo}
+stores it into the union as the integer @code{i}, since it is
+an integer. @xref{Cast to Union}.
+
+You can combine this technique of naming elements with ordinary C
+initialization of successive elements. Each initializer element that
+does not have a designator applies to the next consecutive element of the
+array or structure. For example,
+
+@smallexample
+int a[6] = @{ [1] = v1, v2, [4] = v4 @};
+@end smallexample
+
+@noindent
+is equivalent to
+
+@smallexample
+int a[6] = @{ 0, v1, v2, 0, v4, 0 @};
+@end smallexample
+
+Labeling the elements of an array initializer is especially useful
+when the indices are characters or belong to an @code{enum} type.
+For example:
+
+@smallexample
+int whitespace[256]
+ = @{ [' '] = 1, ['\t'] = 1, ['\h'] = 1,
+ ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 @};
+@end smallexample
+
+@cindex designator lists
+You can also write a series of @samp{.@var{fieldname}} and
+@samp{[@var{index}]} designators before an @samp{=} to specify a
+nested subobject to initialize; the list is taken relative to the
+subobject corresponding to the closest surrounding brace pair. For
+example, with the @samp{struct point} declaration above:
+
+@smallexample
+struct point ptarray[10] = @{ [2].y = yv2, [2].x = xv2, [0].x = xv0 @};
+@end smallexample
+
+If the same field is initialized multiple times, or overlapping
+fields of a union are initialized, the value from the last
+initialization is used. When a field of a union is itself a structure,
+the entire structure from the last field initialized is used. If any previous
+initializer has side effect, it is unspecified whether the side effect
+happens or not. Currently, GCC discards the side-effecting
+initializer expressions and issues a warning.
+
+@node Hex Floats
+@section Hex Floats
+@cindex hex floats
+
+ISO C99 and ISO C++17 support floating-point numbers written not only in
+the usual decimal notation, such as @code{1.55e1}, but also numbers such as
+@code{0x1.fp3} written in hexadecimal format. As a GNU extension, GCC
+supports this in C90 mode (except in some cases when strictly
+conforming) and in C++98, C++11 and C++14 modes. In that format the
+@samp{0x} hex introducer and the @samp{p} or @samp{P} exponent field are
+mandatory. The exponent is a decimal number that indicates the power of
+2 by which the significant part is multiplied. Thus @samp{0x1.f} is
+@tex
+$1 {15\over16}$,
+@end tex
+@ifnottex
+1 15/16,
+@end ifnottex
+@samp{p3} multiplies it by 8, and the value of @code{0x1.fp3}
+is the same as @code{1.55e1}.
+
+Unlike for floating-point numbers in the decimal notation the exponent
+is always required in the hexadecimal notation. Otherwise the compiler
+would not be able to resolve the ambiguity of, e.g., @code{0x1.f}. This
+could mean @code{1.0f} or @code{1.9375} since @samp{f} is also the
+extension for floating-point constants of type @code{float}.
+
+@node Named Address Spaces
+@section Named Address Spaces
+@cindex Named Address Spaces
+
+As an extension, GNU C supports named address spaces as
+defined in the N1275 draft of ISO/IEC DTR 18037. Support for named
+address spaces in GCC will evolve as the draft technical report
+changes. Calling conventions for any target might also change. At
+present, only the AVR, M32C, PRU, RL78, and x86 targets support
+address spaces other than the generic address space.
+
+Address space identifiers may be used exactly like any other C type
+qualifier (e.g., @code{const} or @code{volatile}). See the N1275
+document for more details.
+
+@anchor{AVR Named Address Spaces}
+@subsection AVR Named Address Spaces
+
+On the AVR target, there are several address spaces that can be used
+in order to put read-only data into the flash memory and access that
+data by means of the special instructions @code{LPM} or @code{ELPM}
+needed to read from flash.
+
+Devices belonging to @code{avrtiny} and @code{avrxmega3} can access
+flash memory by means of @code{LD*} instructions because the flash
+memory is mapped into the RAM address space. There is @emph{no need}
+for language extensions like @code{__flash} or attribute
+@ref{AVR Variable Attributes,,@code{progmem}}.
+The default linker description files for these devices cater for that
+feature and @code{.rodata} stays in flash: The compiler just generates
+@code{LD*} instructions, and the linker script adds core specific
+offsets to all @code{.rodata} symbols: @code{0x4000} in the case of
+@code{avrtiny} and @code{0x8000} in the case of @code{avrxmega3}.
+See @ref{AVR Options} for a list of respective devices.
+
+For devices not in @code{avrtiny} or @code{avrxmega3},
+any data including read-only data is located in RAM (the generic
+address space) because flash memory is not visible in the RAM address
+space. In order to locate read-only data in flash memory @emph{and}
+to generate the right instructions to access this data without
+using (inline) assembler code, special address spaces are needed.
+
+@table @code
+@cindex @code{__flash} AVR Named Address Spaces
+@item __flash
+The @code{__flash} qualifier locates data in the
+@code{.progmem.data} section. Data is read using the @code{LPM}
+instruction. Pointers to this address space are 16 bits wide.
+
+@cindex @code{__flash1} AVR Named Address Spaces
+@cindex @code{__flash2} AVR Named Address Spaces
+@cindex @code{__flash3} AVR Named Address Spaces
+@cindex @code{__flash4} AVR Named Address Spaces
+@cindex @code{__flash5} AVR Named Address Spaces
+@item __flash1
+@itemx __flash2
+@itemx __flash3
+@itemx __flash4
+@itemx __flash5
+These are 16-bit address spaces locating data in section
+@code{.progmem@var{N}.data} where @var{N} refers to
+address space @code{__flash@var{N}}.
+The compiler sets the @code{RAMPZ} segment register appropriately
+before reading data by means of the @code{ELPM} instruction.
+
+@cindex @code{__flashx} AVR Named Address Spaces
+@item __flashx
+
+This is a 24-bit flash address space locating data in section
+@code{.progmemx.data}.
+The compiler sets the @code{RAMPZ} segment register appropriately
+before reading data by means of the @code{ELPM} instruction.
+
+@cindex @code{__memx} AVR Named Address Spaces
+@item __memx
+This is a 24-bit address space that linearizes flash and RAM:
+If the high bit of the address is set, data is read from
+RAM using the lower two bytes as RAM address.
+If the high bit of the address is clear, data is read from flash
+with @code{RAMPZ} set according to the high byte of the address.
+@xref{AVR Built-in Functions,,@code{__builtin_avr_flash_segment}}.
+
+Objects in this address space are located in @code{.progmemx.data}.
+@end table
+
+@b{Example}
+
+@smallexample
+char my_read (const __flash char ** p)
+@{
+ /* p is a pointer to RAM that points to a pointer to flash.
+ The first indirection of p reads that flash pointer
+ from RAM and the second indirection reads a char from this
+ flash address. */
+
+ return **p;
+@}
+
+/* Locate array[] in flash memory */
+const __flash int array[] = @{ 3, 5, 7, 11, 13, 17, 19 @};
+
+int i = 1;
+
+int main (void)
+@{
+ /* Return 17 by reading from flash memory */
+ return array[array[i]];
+@}
+@end smallexample
+
+@noindent
+For each named address space supported by avr-gcc there is an equally
+named but uppercase built-in macro defined.
+The purpose is to facilitate testing if respective address space
+support is available or not:
+
+@smallexample
+#ifdef __FLASH
+const __flash int var = 1;
+
+int read_var (void)
+@{
+ return var;
+@}
+#else
+#include <avr/pgmspace.h> /* From AVR-LibC */
+
+const int var PROGMEM = 1;
+
+int read_var (void)
+@{
+ return (int) pgm_read_word (&var);
+@}
+#endif /* __FLASH */
+@end smallexample
+
+@noindent
+Notice that attribute @ref{AVR Variable Attributes,,@code{progmem}}
+locates data in flash but
+accesses to these data read from generic address space, i.e.@:
+from RAM,
+so that you need special accessors like @code{pgm_read_byte}
+from @w{@uref{https://avrdudes.github.io/avr-libc/avr-libc-user-manual/,AVR-LibC}}
+together with attribute @code{progmem}.
+
+@noindent
+@b{Limitations and Caveats}
+
+@itemize
+@item
+Reading across the 64@tie{}KiB section boundary of
+the @code{__flash} or @code{__flash@var{N}} address spaces
+is not supported. The only address spaces that
+support reading across the 64@tie{}KiB flash segment boundaries are
+@code{__memx} and @code{__flashx}.
+
+@item
+If you use one of the @code{__flash@var{N}} address spaces
+you must arrange your linker script to locate the
+@code{.progmem@var{N}.data} sections according to your needs.
+For an example, see the
+@w{@uref{https://gcc.gnu.org/wiki/avr-gcc#Address_Spaces,avr-gcc wiki}}
+
+@item
+Any data or pointers to the non-generic address spaces must
+be qualified as @code{const}, i.e.@: as read-only data.
+This still applies if the data in one of these address
+spaces like software version number or calibration lookup table are intended to
+be changed after load time by, say, a boot loader. In this case
+the right qualification is @code{const} @code{volatile} so that the compiler
+must not optimize away known values or insert them
+as immediates into operands of instructions.
+
+@item
+The following code initializes a variable @code{pfoo}
+located in static storage with a 24-bit address:
+@smallexample
+extern const __memx char foo;
+const __memx void *pfoo = &foo;
+@end smallexample
+
+@item
+On the reduced Tiny devices like ATtiny40, no address spaces are supported.
+Just use vanilla C / C++ code without overhead as outlined above.
+Attribute @code{progmem} is supported but works differently,
+see @ref{AVR Variable Attributes}.
+
+@end itemize
+
+@subsection M32C Named Address Spaces
+@cindex @code{__far} M32C Named Address Spaces
+
+On the M32C target, with the R8C and M16C CPU variants, variables
+qualified with @code{__far} are accessed using 32-bit addresses in
+order to access memory beyond the first 64@tie{}Ki bytes. If
+@code{__far} is used with the M32CM or M32C CPU variants, it has no
+effect.
+
+@subsection PRU Named Address Spaces
+@cindex @code{__regio_symbol} PRU Named Address Spaces
+
+On the PRU target, variables qualified with @code{__regio_symbol} are
+aliases used to access the special I/O CPU registers. They must be
+declared as @code{extern} because such variables will not be allocated in
+any data memory. They must also be marked as @code{volatile}, and can
+only be 32-bit integer types. The only names those variables can have
+are @code{__R30} and @code{__R31}, representing respectively the
+@code{R30} and @code{R31} special I/O CPU registers. Hence the following
+example is the only valid usage of @code{__regio_symbol}:
+
+@smallexample
+extern volatile __regio_symbol uint32_t __R30;
+extern volatile __regio_symbol uint32_t __R31;
+@end smallexample
+
+@subsection RL78 Named Address Spaces
+@cindex @code{__far} RL78 Named Address Spaces
+
+On the RL78 target, variables qualified with @code{__far} are accessed
+with 32-bit pointers (20-bit addresses) rather than the default 16-bit
+addresses. Non-far variables are assumed to appear in the topmost
+64@tie{}KiB of the address space.
+
+@subsection x86 Named Address Spaces
+@cindex x86 named address spaces
+
+On the x86 target, variables may be declared as being relative
+to the @code{%fs} or @code{%gs} segments.
+
+@table @code
+@cindex @code{__seg_fs} x86 named address space
+@cindex @code{__seg_gs} x86 named address space
+@item __seg_fs
+@itemx __seg_gs
+The object is accessed with the respective segment override prefix.
+
+The respective segment base must be set via some method specific to
+the operating system. Rather than require an expensive system call
+to retrieve the segment base, these address spaces are not considered
+to be subspaces of the generic (flat) address space. This means that
+explicit casts are required to convert pointers between these address
+spaces and the generic address space. In practice the application
+should cast to @code{uintptr_t} and apply the segment base offset
+that it installed previously.
+
+The preprocessor symbols @code{__SEG_FS} and @code{__SEG_GS} are
+defined when these address spaces are supported.
+@end table
+
+@node Variadic Macros
+@section Macros with a Variable Number of Arguments.
+@cindex variable number of arguments
+@cindex macro with variable arguments
+@cindex rest argument (in macro)
+@cindex variadic macros
+
+In the ISO C standard of 1999, a macro can be declared to accept a
+variable number of arguments much as a function can. The syntax for
+defining the macro is similar to that of a function. Here is an
+example:
+
+@smallexample
+#define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)
+@end smallexample
+
+@noindent
+Here @samp{@dots{}} is a @dfn{variable argument}. In the invocation of
+such a macro, it represents the zero or more tokens until the closing
+parenthesis that ends the invocation, including any commas. This set of
+tokens replaces the identifier @code{__VA_ARGS__} in the macro body
+wherever it appears. See the CPP manual for more information.
+
+GCC has long supported variadic macros, and used a different syntax that
+allowed you to give a name to the variable arguments just like any other
+argument. Here is an example:
+
+@smallexample
+#define debug(format, args...) fprintf (stderr, format, args)
+@end smallexample
+
+@noindent
+This is in all ways equivalent to the ISO C example above, but arguably
+more readable and descriptive.
+
+GNU CPP has two further variadic macro extensions, and permits them to
+be used with either of the above forms of macro definition.
+
+In standard C, you are not allowed to leave the variable argument out
+entirely; but you are allowed to pass an empty argument. For example,
+this invocation is invalid in ISO C, because there is no comma after
+the string:
+
+@smallexample
+debug ("A message")
+@end smallexample
+
+GNU CPP permits you to completely omit the variable arguments in this
+way. In the above examples, the compiler would complain, though since
+the expansion of the macro still has the extra comma after the format
+string.
+
+To help solve this problem, CPP behaves specially for variable arguments
+used with the token paste operator, @samp{##}. If instead you write
+
+@smallexample
+#define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)
+@end smallexample
+
+@noindent
+and if the variable arguments are omitted or empty, the @samp{##}
+operator causes the preprocessor to remove the comma before it. If you
+do provide some variable arguments in your macro invocation, GNU CPP
+does not complain about the paste operation and instead places the
+variable arguments after the comma. Just like any other pasted macro
+argument, these arguments are not macro expanded.
-@cindex designators
-The @samp{[@var{index}]} or @samp{.@var{fieldname}} is known as a
-@dfn{designator}. You can also use a designator (or the obsolete colon
-syntax) when initializing a union, to specify which element of the union
-should be used. For example,
+@node Escaped Newlines
+@section Slightly Looser Rules for Escaped Newlines
+@cindex escaped newlines
+@cindex newlines (escaped)
-@smallexample
-union foo @{ int i; double d; @};
+The preprocessor treatment of escaped newlines is more relaxed
+than that specified by the C90 standard, which requires the newline
+to immediately follow a backslash.
+GCC's implementation allows whitespace in the form
+of spaces, horizontal and vertical tabs, and form feeds between the
+backslash and the subsequent newline. The preprocessor issues a
+warning, but treats it as a valid escaped newline and combines the two
+lines to form a single logical line. This works within comments and
+tokens, as well as between tokens. Comments are @emph{not} treated as
+whitespace for the purposes of this relaxation, since they have not
+yet been replaced with spaces.
-union foo f = @{ .d = 4 @};
-@end smallexample
+@node Pointer Arith
+@section Arithmetic on @code{void}- and Function-Pointers
+@cindex void pointers, arithmetic
+@cindex void, size of pointer to
+@cindex function pointers, arithmetic
+@cindex function, size of pointer to
-@noindent
-converts 4 to a @code{double} to store it in the union using
-the second element. By contrast, casting 4 to type @code{union foo}
-stores it into the union as the integer @code{i}, since it is
-an integer. @xref{Cast to Union}.
+In GNU C, addition and subtraction operations are supported on pointers to
+@code{void} and on pointers to functions. This is done by treating the
+size of a @code{void} or of a function as 1.
-You can combine this technique of naming elements with ordinary C
-initialization of successive elements. Each initializer element that
-does not have a designator applies to the next consecutive element of the
-array or structure. For example,
+A consequence of this is that @code{sizeof} is also allowed on @code{void}
+and on function types, and returns 1.
-@smallexample
-int a[6] = @{ [1] = v1, v2, [4] = v4 @};
-@end smallexample
+@opindex Wpointer-arith
+The option @option{-Wpointer-arith} requests a warning if these extensions
+are used.
-@noindent
-is equivalent to
+@node Variadic Pointer Args
+@section Pointer Arguments in Variadic Functions
+@cindex pointer arguments in variadic functions
+@cindex variadic functions, pointer arguments
-@smallexample
-int a[6] = @{ 0, v1, v2, 0, v4, 0 @};
-@end smallexample
+Standard C requires that pointer types used with @code{va_arg} in
+functions with variable argument lists either must be compatible with
+that of the actual argument, or that one type must be a pointer to
+@code{void} and the other a pointer to a character type. GNU C
+implements the POSIX XSI extension that additionally permits the use
+of @code{va_arg} with a pointer type to receive arguments of any other
+pointer type.
-Labeling the elements of an array initializer is especially useful
-when the indices are characters or belong to an @code{enum} type.
-For example:
+In particular, in GNU C @samp{va_arg (ap, void *)} can safely be used
+to consume an argument of any pointer type.
-@smallexample
-int whitespace[256]
- = @{ [' '] = 1, ['\t'] = 1, ['\h'] = 1,
- ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 @};
-@end smallexample
+@node Pointers to Arrays
+@section Pointers to Arrays with Qualifiers Work as Expected
+@cindex pointers to arrays
+@cindex const qualifier
-@cindex designator lists
-You can also write a series of @samp{.@var{fieldname}} and
-@samp{[@var{index}]} designators before an @samp{=} to specify a
-nested subobject to initialize; the list is taken relative to the
-subobject corresponding to the closest surrounding brace pair. For
-example, with the @samp{struct point} declaration above:
+In GNU C, pointers to arrays with qualifiers work similar to pointers
+to other qualified types. For example, a value of type @code{int (*)[5]}
+can be used to initialize a variable of type @code{const int (*)[5]}.
+These types are incompatible in ISO C because the @code{const} qualifier
+is formally attached to the element type of the array and not the
+array itself.
@smallexample
-struct point ptarray[10] = @{ [2].y = yv2, [2].x = xv2, [0].x = xv0 @};
+extern void
+transpose (int N, int M, double out[M][N], const double in[N][M]);
+double x[3][2];
+double y[2][3];
+@r{@dots{}}
+transpose(3, 2, y, x);
@end smallexample
-If the same field is initialized multiple times, or overlapping
-fields of a union are initialized, the value from the last
-initialization is used. When a field of a union is itself a structure,
-the entire structure from the last field initialized is used. If any previous
-initializer has side effect, it is unspecified whether the side effect
-happens or not. Currently, GCC discards the side-effecting
-initializer expressions and issues a warning.
-
@node Case Ranges
@section Case Ranges
@cindex case ranges
case 1...5:
@end smallexample
-@node Cast to Union
-@section Cast to a Union Type
-@cindex cast to a union
-@cindex union, casting to a
-
-A cast to a union type is a C extension not available in C++. It looks
-just like ordinary casts with the constraint that the type specified is
-a union type. You can specify the type either with the @code{union}
-keyword or with a @code{typedef} name that refers to a union. The result
-of a cast to a union is a temporary rvalue of the union type with a member
-whose type matches that of the operand initialized to the value of
-the operand. The effect of a cast to a union is similar to a compound
-literal except that it yields an rvalue like standard casts do.
-@xref{Compound Literals}.
-
-Expressions that may be cast to the union type are those whose type matches
-at least one of the members of the union. Thus, given the following union
-and variables:
-
-@smallexample
-union foo @{ int i; double d; @};
-int x;
-double y;
-union foo z;
-@end smallexample
-
-@noindent
-both @code{x} and @code{y} can be cast to type @code{union foo} and
-the following assignments
-@smallexample
- z = (union foo) x;
- z = (union foo) y;
-@end smallexample
-are shorthand equivalents of these
-@smallexample
- z = (union foo) @{ .i = x @};
- z = (union foo) @{ .d = y @};
-@end smallexample
-
-However, @code{(union foo) FLT_MAX;} is not a valid cast because the union
-has no member of type @code{float}.
-
-Using the cast as the right-hand side of an assignment to a variable of
-union type is equivalent to storing in a member of the union with
-the same type
-
-@smallexample
-union foo u;
-/* @r{@dots{}} */
-u = (union foo) x @equiv{} u.i = x
-u = (union foo) y @equiv{} u.d = y
-@end smallexample
-
-You can also use the union cast as a function argument:
-
-@smallexample
-void hack (union foo);
-/* @r{@dots{}} */
-hack ((union foo) x);
-@end smallexample
-
@node Mixed Labels and Declarations
@section Mixed Declarations, Labels and Code
@cindex mixed declarations and code
@end table
-@node Unnamed Fields
-@section Unnamed Structure and Union Fields
-@cindex @code{struct}
-@cindex @code{union}
-
-As permitted by ISO C11 and for compatibility with other compilers,
-GCC allows you to define
-a structure or union that contains, as fields, structures and unions
-without names. For example:
-
-@smallexample
-struct @{
- int a;
- union @{
- int b;
- float c;
- @};
- int d;
-@} foo;
-@end smallexample
-
-@noindent
-In this example, you are able to access members of the unnamed
-union with code like @samp{foo.b}. Note that only unnamed structs and
-unions are allowed, you may not have, for example, an unnamed
-@code{int}.
-
-You must never create such structures that cause ambiguous field definitions.
-For example, in this structure:
-
-@smallexample
-struct @{
- int a;
- struct @{
- int a;
- @};
-@} foo;
-@end smallexample
-
-@noindent
-it is ambiguous which @code{a} is being referred to with @samp{foo.a}.
-The compiler gives errors for such constructs.
-
-@opindex fms-extensions
-Unless @option{-fms-extensions} is used, the unnamed field must be a
-structure or union definition without a tag (for example, @samp{struct
-@{ int a; @};}). If @option{-fms-extensions} is used, the field may
-also be a definition with a tag such as @samp{struct foo @{ int a;
-@};}, a reference to a previously defined structure or union such as
-@samp{struct foo;}, or a reference to a @code{typedef} name for a
-previously defined structure or union type.
-
-@opindex fplan9-extensions
-The option @option{-fplan9-extensions} enables
-@option{-fms-extensions} as well as two other extensions. First, a
-pointer to a structure is automatically converted to a pointer to an
-anonymous field for assignments and function calls. For example:
-
-@smallexample
-struct s1 @{ int a; @};
-struct s2 @{ struct s1; @};
-extern void f1 (struct s1 *);
-void f2 (struct s2 *p) @{ f1 (p); @}
-@end smallexample
-
-@noindent
-In the call to @code{f1} inside @code{f2}, the pointer @code{p} is
-converted into a pointer to the anonymous field.
-
-Second, when the type of an anonymous field is a @code{typedef} for a
-@code{struct} or @code{union}, code may refer to the field using the
-name of the @code{typedef}.
-
-@smallexample
-typedef struct @{ int a; @} s1;
-struct s2 @{ s1; @};
-s1 f1 (struct s2 *p) @{ return p->s1; @}
-@end smallexample
-
-These usages are only permitted when they are not ambiguous.
-
@node Thread-Local
@section Thread-Local Storage
@cindex Thread-Local Storage
projects / thirdparty / gcc.git / commitdiff
