This is doc/gcc.info, produced by makeinfo version 4.5 from doc/gcc.texi. INFO-DIR-SECTION Programming START-INFO-DIR-ENTRY * gcc: (gcc). The GNU Compiler Collection. END-INFO-DIR-ENTRY This file documents the use of the GNU compilers. Published by the Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being "GNU General Public License" and "Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled "GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.  File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC Options for Code Generation Conventions ======================================= These machine-independent options control the interface conventions used in code generation. Most of them have both positive and negative forms; the negative form of `-ffoo' would be `-fno-foo'. In the table below, only one of the forms is listed--the one which is not the default. You can figure out the other form by either removing `no-' or adding it. `-fexceptions' Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies GCC will generate frame unwind information for all functions, which can produce significant data size overhead, although it does not affect execution. If you do not specify this option, GCC will enable it by default for languages like C++ which normally require exception handling, and disable it for languages like C that do not normally require it. However, you may need to enable this option when compiling C code that needs to interoperate properly with exception handlers written in C++. You may also wish to disable this option if you are compiling older C++ programs that don't use exception handling. `-fnon-call-exceptions' Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support that does not exist everywhere. Moreover, it only allows _trapping_ instructions to throw exceptions, i.e. memory references or floating point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as `SIGALRM'. `-funwind-tables' Similar to `-fexceptions', except that it will just generate any needed static data, but will not affect the generated code in any other way. You will normally not enable this option; instead, a language processor that needs this handling would enable it on your behalf. `-fasynchronous-unwind-tables' Generate unwind table in dwarf2 format, if supported by target machine. The table is exact at each instruction boundary, so it can be used for stack unwinding from asynchronous events (such as debugger or garbage collector). `-fpcc-struct-return' Return "short" `struct' and `union' values in memory like longer ones, rather than in registers. This convention is less efficient, but it has the advantage of allowing intercallability between GCC-compiled files and files compiled with other compilers, particularly the Portable C Compiler (pcc). The precise convention for returning structures in memory depends on the target configuration macros. Short structures and unions are those whose size and alignment match that of some integer type. *Warning:* code compiled with the `-fpcc-struct-return' switch is not binary compatible with code compiled with the `-freg-struct-return' switch. Use it to conform to a non-default application binary interface. `-freg-struct-return' Return `struct' and `union' values in registers when possible. This is more efficient for small structures than `-fpcc-struct-return'. If you specify neither `-fpcc-struct-return' nor `-freg-struct-return', GCC defaults to whichever convention is standard for the target. If there is no standard convention, GCC defaults to `-fpcc-struct-return', except on targets where GCC is the principal compiler. In those cases, we can choose the standard, and we chose the more efficient register return alternative. *Warning:* code compiled with the `-freg-struct-return' switch is not binary compatible with code compiled with the `-fpcc-struct-return' switch. Use it to conform to a non-default application binary interface. `-fshort-enums' Allocate to an `enum' type only as many bytes as it needs for the declared range of possible values. Specifically, the `enum' type will be equivalent to the smallest integer type which has enough room. *Warning:* the `-fshort-enums' switch causes GCC to generate code that is not binary compatible with code generated without that switch. Use it to conform to a non-default application binary interface. `-fshort-double' Use the same size for `double' as for `float'. *Warning:* the `-fshort-double' switch causes GCC to generate code that is not binary compatible with code generated without that switch. Use it to conform to a non-default application binary interface. `-fshort-wchar' Override the underlying type for `wchar_t' to be `short unsigned int' instead of the default for the target. This option is useful for building programs to run under WINE. *Warning:* the `-fshort-wchar' switch causes GCC to generate code that is not binary compatible with code generated without that switch. Use it to conform to a non-default application binary interface. `-fshared-data' Requests that the data and non-`const' variables of this compilation be shared data rather than private data. The distinction makes sense only on certain operating systems, where shared data is shared between processes running the same program, while private data exists in one copy per process. `-fno-common' In C, allocate even uninitialized global variables in the data section of the object file, rather than generating them as common blocks. This has the effect that if the same variable is declared (without `extern') in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the program will work on other systems which always work this way. `-fno-ident' Ignore the `#ident' directive. `-fno-gnu-linker' Do not output global initializations (such as C++ constructors and destructors) in the form used by the GNU linker (on systems where the GNU linker is the standard method of handling them). Use this option when you want to use a non-GNU linker, which also requires using the `collect2' program to make sure the system linker includes constructors and destructors. (`collect2' is included in the GCC distribution.) For systems which _must_ use `collect2', the compiler driver `gcc' is configured to do this automatically. `-finhibit-size-directive' Don't output a `.size' assembler directive, or anything else that would cause trouble if the function is split in the middle, and the two halves are placed at locations far apart in memory. This option is used when compiling `crtstuff.c'; you should not need to use it for anything else. `-fverbose-asm' Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (perhaps while debugging the compiler itself). `-fno-verbose-asm', the default, causes the extra information to be omitted and is useful when comparing two assembler files. `-fvolatile' Consider all memory references through pointers to be volatile. `-fvolatile-global' Consider all memory references to extern and global data items to be volatile. GCC does not consider static data items to be volatile because of this switch. `-fvolatile-static' Consider all memory references to static data to be volatile. `-fpic' Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that `-fpic' does not work; in that case, recompile with `-fPIC' instead. (These maximums are 16k on the m88k, 8k on the Sparc, and 32k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires special support, and therefore works only on certain machines. For the 386, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent. `-fPIC' If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, m88k, and the Sparc. Position-independent code requires special support, and therefore works only on certain machines. `-ffixed-REG' Treat the register named REG as a fixed register; generated code should never refer to it (except perhaps as a stack pointer, frame pointer or in some other fixed role). REG must be the name of a register. The register names accepted are machine-specific and are defined in the `REGISTER_NAMES' macro in the machine description macro file. This flag does not have a negative form, because it specifies a three-way choice. `-fcall-used-REG' Treat the register named REG as an allocable register that is clobbered by function calls. It may be allocated for temporaries or variables that do not live across a call. Functions compiled this way will not save and restore the register REG. It is an error to used this flag with the frame pointer or stack pointer. Use of this flag for other registers that have fixed pervasive roles in the machine's execution model will produce disastrous results. This flag does not have a negative form, because it specifies a three-way choice. `-fcall-saved-REG' Treat the register named REG as an allocable register saved by functions. It may be allocated even for temporaries or variables that live across a call. Functions compiled this way will save and restore the register REG if they use it. It is an error to used this flag with the frame pointer or stack pointer. Use of this flag for other registers that have fixed pervasive roles in the machine's execution model will produce disastrous results. A different sort of disaster will result from the use of this flag for a register in which function values may be returned. This flag does not have a negative form, because it specifies a three-way choice. `-fpack-struct' Pack all structure members together without holes. *Warning:* the `-fpack-struct' switch causes GCC to generate code that is not binary compatible with code generated without that switch. Additionally, it makes the code suboptimial. Use it to conform to a non-default application binary interface. `-finstrument-functions' Generate instrumentation calls for entry and exit to functions. Just after function entry and just before function exit, the following profiling functions will be called with the address of the current function and its call site. (On some platforms, `__builtin_return_address' does not work beyond the current function, so the call site information may not be available to the profiling functions otherwise.) void __cyg_profile_func_enter (void *this_fn, void *call_site); void __cyg_profile_func_exit (void *this_fn, void *call_site); The first argument is the address of the start of the current function, which may be looked up exactly in the symbol table. This instrumentation is also done for functions expanded inline in other functions. The profiling calls will indicate where, conceptually, the inline function is entered and exited. This means that addressable versions of such functions must be available. If all your uses of a function are expanded inline, this may mean an additional expansion of code size. If you use `extern inline' in your C code, an addressable version of such functions must be provided. (This is normally the case anyways, but if you get lucky and the optimizer always expands the functions inline, you might have gotten away without providing static copies.) A function may be given the attribute `no_instrument_function', in which case this instrumentation will not be done. This can be used, for example, for the profiling functions listed above, high-priority interrupt routines, and any functions from which the profiling functions cannot safely be called (perhaps signal handlers, if the profiling routines generate output or allocate memory). `-fstack-check' Generate code to verify that you do not go beyond the boundary of the stack. You should specify this flag if you are running in an environment with multiple threads, but only rarely need to specify it in a single-threaded environment since stack overflow is automatically detected on nearly all systems if there is only one stack. Note that this switch does not actually cause checking to be done; the operating system must do that. The switch causes generation of code to ensure that the operating system sees the stack being extended. `-fstack-limit-register=REG' `-fstack-limit-symbol=SYM' `-fno-stack-limit' Generate code to ensure that the stack does not grow beyond a certain value, either the value of a register or the address of a symbol. If the stack would grow beyond the value, a signal is raised. For most targets, the signal is raised before the stack overruns the boundary, so it is possible to catch the signal without taking special precautions. For instance, if the stack starts at absolute address `0x80000000' and grows downwards, you can use the flags `-fstack-limit-symbol=__stack_limit' and `-Wl,--defsym,__stack_limit=0x7ffe0000' to enforce a stack limit of 128KB. Note that this may only work with the GNU linker. `-fargument-alias' `-fargument-noalias' `-fargument-noalias-global' Specify the possible relationships among parameters and between parameters and global data. `-fargument-alias' specifies that arguments (parameters) may alias each other and may alias global storage. `-fargument-noalias' specifies that arguments do not alias each other, but may alias global storage. `-fargument-noalias-global' specifies that arguments do not alias each other and do not alias global storage. Each language will automatically use whatever option is required by the language standard. You should not need to use these options yourself. `-fleading-underscore' This option and its counterpart, `-fno-leading-underscore', forcibly change the way C symbols are represented in the object file. One use is to help link with legacy assembly code. *Warning:* the `-fleading-underscore' switch causes GCC to generate code that is not binary compatible with code generated without that switch. Use it to conform to a non-default application binary interface. Not all targets provide complete support for this switch.  File: gcc.info, Node: Environment Variables, Next: Running Protoize, Prev: Code Gen Options, Up: Invoking GCC Environment Variables Affecting GCC =================================== This section describes several environment variables that affect how GCC operates. Some of them work by specifying directories or prefixes to use when searching for various kinds of files. Some are used to specify other aspects of the compilation environment. Note that you can also specify places to search using options such as `-B', `-I' and `-L' (*note Directory Options::). These take precedence over places specified using environment variables, which in turn take precedence over those specified by the configuration of GCC. *Note Controlling the Compilation Driver `gcc': (gccint)Driver. `LANG' `LC_CTYPE' `LC_MESSAGES' `LC_ALL' These environment variables control the way that GCC uses localization information that allow GCC to work with different national conventions. GCC inspects the locale categories `LC_CTYPE' and `LC_MESSAGES' if it has been configured to do so. These locale categories can be set to any value supported by your installation. A typical value is `en_UK' for English in the United Kingdom. The `LC_CTYPE' environment variable specifies character classification. GCC uses it to determine the character boundaries in a string; this is needed for some multibyte encodings that contain quote and escape characters that would otherwise be interpreted as a string end or escape. The `LC_MESSAGES' environment variable specifies the language to use in diagnostic messages. If the `LC_ALL' environment variable is set, it overrides the value of `LC_CTYPE' and `LC_MESSAGES'; otherwise, `LC_CTYPE' and `LC_MESSAGES' default to the value of the `LANG' environment variable. If none of these variables are set, GCC defaults to traditional C English behavior. `TMPDIR' If `TMPDIR' is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. `GCC_EXEC_PREFIX' If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the names of the subprograms executed by the compiler. No slash is added when this prefix is combined with the name of a subprogram, but you can specify a prefix that ends with a slash if you wish. If `GCC_EXEC_PREFIX' is not set, GCC will attempt to figure out an appropriate prefix to use based on the pathname it was invoked with. If GCC cannot find the subprogram using the specified prefix, it tries looking in the usual places for the subprogram. The default value of `GCC_EXEC_PREFIX' is `PREFIX/lib/gcc-lib/' where PREFIX is the value of `prefix' when you ran the `configure' script. Other prefixes specified with `-B' take precedence over this prefix. This prefix is also used for finding files such as `crt0.o' that are used for linking. In addition, the prefix is used in an unusual way in finding the directories to search for header files. For each of the standard directories whose name normally begins with `/usr/local/lib/gcc-lib' (more precisely, with the value of `GCC_INCLUDE_DIR'), GCC tries replacing that beginning with the specified prefix to produce an alternate directory name. Thus, with `-Bfoo/', GCC will search `foo/bar' where it would normally search `/usr/local/lib/bar'. These alternate directories are searched first; the standard directories come next. `COMPILER_PATH' The value of `COMPILER_PATH' is a colon-separated list of directories, much like `PATH'. GCC tries the directories thus specified when searching for subprograms, if it can't find the subprograms using `GCC_EXEC_PREFIX'. `LIBRARY_PATH' The value of `LIBRARY_PATH' is a colon-separated list of directories, much like `PATH'. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it can't find them using `GCC_EXEC_PREFIX'. Linking using GCC also uses these directories when searching for ordinary libraries for the `-l' option (but directories specified with `-L' come first). `LANG' This variable is used to pass locale information to the compiler. One way in which this information is used is to determine the character set to be used when character literals, string literals and comments are parsed in C and C++. When the compiler is configured to allow multibyte characters, the following values for `LANG' are recognized: `C-JIS' Recognize JIS characters. `C-SJIS' Recognize SJIS characters. `C-EUCJP' Recognize EUCJP characters. If `LANG' is not defined, or if it has some other value, then the compiler will use mblen and mbtowc as defined by the default locale to recognize and translate multibyte characters. Some additional environments variables affect the behavior of the preprocessor. `CPATH' `C_INCLUDE_PATH' `CPLUS_INCLUDE_PATH' `OBJC_INCLUDE_PATH' Each variable's value is a list of directories separated by a special character, much like `PATH', in which to look for header files. The special character, `PATH_SEPARATOR', is target-dependent and determined at GCC build time. For Windows-based targets it is a semicolon, and for almost all other targets it is a colon. `CPATH' specifies a list of directories to be searched as if specified with `-I', but after any paths given with `-I' options on the command line. The environment variable is used regardless of which language is being preprocessed. The remaining environment variables apply only when preprocessing the particular language indicated. Each specifies a list of directories to be searched as if specified with `-isystem', but after any paths given with `-isystem' options on the command line. `DEPENDENCIES_OUTPUT' If this variable is set, its value specifies how to output dependencies for Make based on the non-system header files processed by the compiler. System header files are ignored in the dependency output. The value of `DEPENDENCIES_OUTPUT' can be just a file name, in which case the Make rules are written to that file, guessing the target name from the source file name. Or the value can have the form `FILE TARGET', in which case the rules are written to file FILE using TARGET as the target name. In other words, this environment variable is equivalent to combining the options `-MM' and `-MF' (*note Preprocessor Options::), with an optional `-MT' switch too. `SUNPRO_DEPENDENCIES' This variable is the same as the environment variable `DEPENDENCIES_OUTPUT' (*note DEPENDENCIES_OUTPUT::), except that system header files are not ignored, so it implies `-M' rather than `-MM'. However, the dependence on the main input file is omitted. *Note Preprocessor Options::.  File: gcc.info, Node: Running Protoize, Prev: Environment Variables, Up: Invoking GCC Running Protoize ================ The program `protoize' is an optional part of GCC. You can use it to add prototypes to a program, thus converting the program to ISO C in one respect. The companion program `unprotoize' does the reverse: it removes argument types from any prototypes that are found. When you run these programs, you must specify a set of source files as command line arguments. The conversion programs start out by compiling these files to see what functions they define. The information gathered about a file FOO is saved in a file named `FOO.X'. After scanning comes actual conversion. The specified files are all eligible to be converted; any files they include (whether sources or just headers) are eligible as well. But not all the eligible files are converted. By default, `protoize' and `unprotoize' convert only source and header files in the current directory. You can specify additional directories whose files should be converted with the `-d DIRECTORY' option. You can also specify particular files to exclude with the `-x FILE' option. A file is converted if it is eligible, its directory name matches one of the specified directory names, and its name within the directory has not been excluded. Basic conversion with `protoize' consists of rewriting most function definitions and function declarations to specify the types of the arguments. The only ones not rewritten are those for varargs functions. `protoize' optionally inserts prototype declarations at the beginning of the source file, to make them available for any calls that precede the function's definition. Or it can insert prototype declarations with block scope in the blocks where undeclared functions are called. Basic conversion with `unprotoize' consists of rewriting most function declarations to remove any argument types, and rewriting function definitions to the old-style pre-ISO form. Both conversion programs print a warning for any function declaration or definition that they can't convert. You can suppress these warnings with `-q'. The output from `protoize' or `unprotoize' replaces the original source file. The original file is renamed to a name ending with `.save' (for DOS, the saved filename ends in `.sav' without the original `.c' suffix). If the `.save' (`.sav' for DOS) file already exists, then the source file is simply discarded. `protoize' and `unprotoize' both depend on GCC itself to scan the program and collect information about the functions it uses. So neither of these programs will work until GCC is installed. Here is a table of the options you can use with `protoize' and `unprotoize'. Each option works with both programs unless otherwise stated. `-B DIRECTORY' Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the usual directory (normally `/usr/local/lib'). This file contains prototype information about standard system functions. This option applies only to `protoize'. `-c COMPILATION-OPTIONS' Use COMPILATION-OPTIONS as the options when running `gcc' to produce the `.X' files. The special option `-aux-info' is always passed in addition, to tell `gcc' to write a `.X' file. Note that the compilation options must be given as a single argument to `protoize' or `unprotoize'. If you want to specify several `gcc' options, you must quote the entire set of compilation options to make them a single word in the shell. There are certain `gcc' arguments that you cannot use, because they would produce the wrong kind of output. These include `-g', `-O', `-c', `-S', and `-o' If you include these in the COMPILATION-OPTIONS, they are ignored. `-C' Rename files to end in `.C' (`.cc' for DOS-based file systems) instead of `.c'. This is convenient if you are converting a C program to C++. This option applies only to `protoize'. `-g' Add explicit global declarations. This means inserting explicit declarations at the beginning of each source file for each function that is called in the file and was not declared. These declarations precede the first function definition that contains a call to an undeclared function. This option applies only to `protoize'. `-i STRING' Indent old-style parameter declarations with the string STRING. This option applies only to `protoize'. `unprotoize' converts prototyped function definitions to old-style function definitions, where the arguments are declared between the argument list and the initial `{'. By default, `unprotoize' uses five spaces as the indentation. If you want to indent with just one space instead, use `-i " "'. `-k' Keep the `.X' files. Normally, they are deleted after conversion is finished. `-l' Add explicit local declarations. `protoize' with `-l' inserts a prototype declaration for each function in each block which calls the function without any declaration. This option applies only to `protoize'. `-n' Make no real changes. This mode just prints information about the conversions that would have been done without `-n'. `-N' Make no `.save' files. The original files are simply deleted. Use this option with caution. `-p PROGRAM' Use the program PROGRAM as the compiler. Normally, the name `gcc' is used. `-q' Work quietly. Most warnings are suppressed. `-v' Print the version number, just like `-v' for `gcc'. If you need special compiler options to compile one of your program's source files, then you should generate that file's `.X' file specially, by running `gcc' on that source file with the appropriate options and the option `-aux-info'. Then run `protoize' on the entire set of files. `protoize' will use the existing `.X' file because it is newer than the source file. For example: gcc -Dfoo=bar file1.c -aux-info file1.X protoize *.c You need to include the special files along with the rest in the `protoize' command, even though their `.X' files already exist, because otherwise they won't get converted. *Note Protoize Caveats::, for more information on how to use `protoize' successfully.  File: gcc.info, Node: C Implementation, Next: C Extensions, Prev: Invoking GCC, Up: Top C Implementation-defined behavior ********************************* A conforming implementation of ISO C is required to document its choice of behavior in each of the areas that are designated "implementation defined." The following lists all such areas, along with the section number from the ISO/IEC 9899:1999 standard. * Menu: * Translation implementation:: * Environment implementation:: * Identifiers implementation:: * Characters implementation:: * Integers implementation:: * Floating point implementation:: * Arrays and pointers implementation:: * Hints implementation:: * Structures unions enumerations and bit-fields implementation:: * Qualifiers implementation:: * Preprocessing directives implementation:: * Library functions implementation:: * Architecture implementation:: * Locale-specific behavior implementation::  File: gcc.info, Node: Translation implementation, Next: Environment implementation, Up: C Implementation Translation =========== * `How a diagnostic is identified (3.10, 5.1.1.3).' * `Whether each nonempty sequence of white-space characters other than new-line is retained or replaced by one space character in translation phase 3 (5.1.1.2).'  File: gcc.info, Node: Environment implementation, Next: Identifiers implementation, Prev: Translation implementation, Up: C Implementation Environment =========== The behavior of these points are dependent on the implementation of the C library, and are not defined by GCC itself.  File: gcc.info, Node: Identifiers implementation, Next: Characters implementation, Prev: Environment implementation, Up: C Implementation Identifiers =========== * `Which additional multibyte characters may appear in identifiers and their correspondence to universal character names (6.4.2).' * `The number of significant initial characters in an identifier (5.2.4.1, 6.4.2).'  File: gcc.info, Node: Characters implementation, Next: Integers implementation, Prev: Identifiers implementation, Up: C Implementation Characters ========== * `The number of bits in a byte (3.6).' * `The values of the members of the execution character set (5.2.1).' * `The unique value of the member of the execution character set produced for each of the standard alphabetic escape sequences (5.2.2).' * `The value of a `char' object into which has been stored any character other than a member of the basic execution character set (6.2.5).' * `Which of `signed char' or `unsigned char' has the same range, representation, and behavior as "plain" `char' (6.2.5, 6.3.1.1).' * `The mapping of members of the source character set (in character constants and string literals) to members of the execution character set (6.4.4.4, 5.1.1.2).' * `The value of an integer character constant containing more than one character or containing a character or escape sequence that does not map to a single-byte execution character (6.4.4.4).' * `The value of a wide character constant containing more than one multibyte character, or containing a multibyte character or escape sequence not represented in the extended execution character set (6.4.4.4).' * `The current locale used to convert a wide character constant consisting of a single multibyte character that maps to a member of the extended execution character set into a corresponding wide character code (6.4.4.4).' * `The current locale used to convert a wide string literal into corresponding wide character codes (6.4.5).' * `The value of a string literal containing a multibyte character or escape sequence not represented in the execution character set (6.4.5).'  File: gcc.info, Node: Integers implementation, Next: Floating point implementation, Prev: Characters implementation, Up: C Implementation Integers ======== * `Any extended integer types that exist in the implementation (6.2.5).' * `Whether signed integer types are represented using sign and magnitude, two's complement, or one's complement, and whether the extraordinary value is a trap representation or an ordinary value (6.2.6.2).' * `The rank of any extended integer type relative to another extended integer type with the same precision (6.3.1.1).' * `The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (6.3.1.3).' * `The results of some bitwise operations on signed integers (6.5).'  File: gcc.info, Node: Floating point implementation, Next: Arrays and pointers implementation, Prev: Integers implementation, Up: C Implementation Floating point ============== * `The accuracy of the floating-point operations and of the library functions in `' and `' that return floating-point results (5.2.4.2.2).' * `The rounding behaviors characterized by non-standard values of `FLT_ROUNDS' (5.2.4.2.2).' * `The evaluation methods characterized by non-standard negative values of `FLT_EVAL_METHOD' (5.2.4.2.2).' * `The direction of rounding when an integer is converted to a floating-point number that cannot exactly represent the original value (6.3.1.4).' * `The direction of rounding when a floating-point number is converted to a narrower floating-point number (6.3.1.5).' * `How the nearest representable value or the larger or smaller representable value immediately adjacent to the nearest representable value is chosen for certain floating constants (6.4.4.2).' * `Whether and how floating expressions are contracted when not disallowed by the `FP_CONTRACT' pragma (6.5).' * `The default state for the `FENV_ACCESS' pragma (7.6.1).' * `Additional floating-point exceptions, rounding modes, environments, and classifications, and their macro names (7.6, 7.12).' * `The default state for the `FP_CONTRACT' pragma (7.12.2).' * `Whether the "inexact" floating-point exception can be raised when the rounded result actually does equal the mathematical result in an IEC 60559 conformant implementation (F.9).' * `Whether the "underflow" (and "inexact") floating-point exception can be raised when a result is tiny but not inexact in an IEC 60559 conformant implementation (F.9).'  File: gcc.info, Node: Arrays and pointers implementation, Next: Hints implementation, Prev: Floating point implementation, Up: C Implementation Arrays and pointers =================== * `The result of converting a pointer to an integer or vice versa (6.3.2.3).' A cast from pointer to integer discards most-significant bits if the pointer representation is larger than the integer type, sign-extends(1) if the pointer representation is smaller than the integer type, otherwise the bits are unchanged. A cast from integer to pointer discards most-significant bits if the pointer representation is smaller than the integer type, extends according to the signedness of the integer type if the pointer representation is larger than the integer type, otherwise the bits are unchanged. When casting from pointer to integer and back again, the resulting pointer must reference the same object as the original pointer, otherwise the behavior is undefined. That is, one may not use integer arithmetic to avoid the undefined behavior of pointer arithmetic as proscribed in 6.5.6/8. * `The size of the result of subtracting two pointers to elements of the same array (6.5.6).' ---------- Footnotes ---------- (1) Future versions of GCC may zero-extend, or use a target-defined `ptr_extend' pattern. Do not rely on sign extension.  File: gcc.info, Node: Hints implementation, Next: Structures unions enumerations and bit-fields implementation, Prev: Arrays and pointers implementation, Up: C Implementation Hints ===== * `The extent to which suggestions made by using the `register' storage-class specifier are effective (6.7.1).' * `The extent to which suggestions made by using the inline function specifier are effective (6.7.4).'  File: gcc.info, Node: Structures unions enumerations and bit-fields implementation, Next: Qualifiers implementation, Prev: Hints implementation, Up: C Implementation Structures, unions, enumerations, and bit-fields ================================================ * `Whether a "plain" int bit-field is treated as a `signed int' bit-field or as an `unsigned int' bit-field (6.7.2, 6.7.2.1).' * `Allowable bit-field types other than `_Bool', `signed int', and `unsigned int' (6.7.2.1).' * `Whether a bit-field can straddle a storage-unit boundary (6.7.2.1).' * `The order of allocation of bit-fields within a unit (6.7.2.1).' * `The alignment of non-bit-field members of structures (6.7.2.1).' * `The integer type compatible with each enumerated type (6.7.2.2).'  File: gcc.info, Node: Qualifiers implementation, Next: Preprocessing directives implementation, Prev: Structures unions enumerations and bit-fields implementation, Up: C Implementation Qualifiers ========== * `What constitutes an access to an object that has volatile-qualified type (6.7.3).'  File: gcc.info, Node: Preprocessing directives implementation, Next: Library functions implementation, Prev: Qualifiers implementation, Up: C Implementation Preprocessing directives ======================== * `How sequences in both forms of header names are mapped to headers or external source file names (6.4.7).' * `Whether the value of a character constant in a constant expression that controls conditional inclusion matches the value of the same character constant in the execution character set (6.10.1).' * `Whether the value of a single-character character constant in a constant expression that controls conditional inclusion may have a negative value (6.10.1).' * `The places that are searched for an included `<>' delimited header, and how the places are specified or the header is identified (6.10.2).' * `How the named source file is searched for in an included `""' delimited header (6.10.2).' * `The method by which preprocessing tokens (possibly resulting from macro expansion) in a `#include' directive are combined into a header name (6.10.2).' * `The nesting limit for `#include' processing (6.10.2).' * `Whether the `#' operator inserts a `\' character before the `\' character that begins a universal character name in a character constant or string literal (6.10.3.2).' * `The behavior on each recognized non-`STDC #pragma' directive (6.10.6).' * `The definitions for `__DATE__' and `__TIME__' when respectively, the date and time of translation are not available (6.10.8).'  File: gcc.info, Node: Library functions implementation, Next: Architecture implementation, Prev: Preprocessing directives implementation, Up: C Implementation Library functions ================= The behavior of these points are dependent on the implementation of the C library, and are not defined by GCC itself.  File: gcc.info, Node: Architecture implementation, Next: Locale-specific behavior implementation, Prev: Library functions implementation, Up: C Implementation Architecture ============ * `The values or expressions assigned to the macros specified in the headers `', `', and `' (5.2.4.2, 7.18.2, 7.18.3).' * `The number, order, and encoding of bytes in any object (when not explicitly specified in this International Standard) (6.2.6.1).' * `The value of the result of the sizeof operator (6.5.3.4).'  File: gcc.info, Node: Locale-specific behavior implementation, Prev: Architecture implementation, Up: C Implementation Locale-specific behavior ======================== The behavior of these points are dependent on the implementation of the C library, and are not defined by GCC itself.  File: gcc.info, Node: C Extensions, Next: C++ Extensions, Prev: C Implementation, Up: Top Extensions to the C Language Family *********************************** GNU C provides several language features not found in ISO standard C. (The `-pedantic' option directs GCC to print a warning message if any of these features is used.) To test for the availability of these features in conditional compilation, check for a predefined macro `__GNUC__', which is always defined under GCC. These extensions are available in C and Objective-C. Most of them are also available in C++. *Note Extensions to the C++ Language: C++ Extensions, for extensions that apply _only_ to C++. Some features that are in ISO C99 but not C89 or C++ are also, as extensions, accepted by GCC in C89 mode and in C++. * Menu: * Statement Exprs:: Putting statements and declarations inside expressions. * Local Labels:: Labels local to a statement-expression. * Labels as Values:: Getting pointers to labels, and computed gotos. * Nested Functions:: As in Algol and Pascal, lexical scoping of functions. * Constructing Calls:: Dispatching a call to another function. * Typeof:: `typeof': referring to the type of an expression. * Lvalues:: Using `?:', `,' and casts in lvalues. * Conditionals:: Omitting the middle operand of a `?:' expression. * Long Long:: Double-word integers---`long long int'. * Complex:: Data types for complex numbers. * Hex Floats:: Hexadecimal floating-point constants. * Zero Length:: Zero-length arrays. * 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. * Multi-line Strings:: String literals with embedded newlines. * Subscripting:: Any array can be subscripted, even if not an lvalue. * Pointer Arith:: Arithmetic on `void'-pointers and function pointers. * Initializers:: Non-constant initializers. * Compound Literals:: Compound literals give structures, unions or arrays as values. * Designated Inits:: Labeling elements of initializers. * Cast to Union:: Casting to union type from any member of the union. * Case Ranges:: `case 1 ... 9' and such. * Mixed Declarations:: Mixing declarations and code. * Function Attributes:: Declaring that functions have no side effects, or that they can never return. * Attribute Syntax:: Formal syntax for attributes. * Function Prototypes:: Prototype declarations and old-style definitions. * C++ Comments:: C++ comments are recognized. * Dollar Signs:: Dollar sign is allowed in identifiers. * Character Escapes:: `\e' stands for the character . * Variable Attributes:: Specifying attributes of variables. * Type Attributes:: Specifying attributes of types. * Alignment:: Inquiring about the alignment of a type or variable. * Inline:: Defining inline functions (as fast as macros). * Extended Asm:: Assembler instructions with C expressions as operands. (With them you can define ``built-in'' functions.) * Constraints:: Constraints for asm operands * Asm Labels:: Specifying the assembler name to use for a C symbol. * Explicit Reg Vars:: Defining variables residing in specified registers. * Alternate Keywords:: `__const__', `__asm__', etc., for header files. * Incomplete Enums:: `enum foo;', with details to follow. * Function Names:: Printable strings which are the name of the current function. * Return Address:: Getting the return or frame address of a function. * Vector Extensions:: Using vector instructions through built-in functions. * Other Builtins:: Other built-in functions. * Target Builtins:: Built-in functions specific to particular targets. * Pragmas:: Pragmas accepted by GCC. * Unnamed Fields:: Unnamed struct/union fields within structs/unions.  File: gcc.info, Node: Statement Exprs, Next: Local Labels, Up: C Extensions Statements and Declarations in Expressions ========================================== A compound statement enclosed in parentheses may appear as an expression in GNU C. This allows you to use loops, switches, and local variables within an expression. Recall that a compound statement is a sequence of statements surrounded by braces; in this construct, parentheses go around the braces. For example: ({ int y = foo (); int z; if (y > 0) z = y; else z = - y; z; }) is a valid (though slightly more complex than necessary) expression for the absolute value of `foo ()'. The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. (If you use some other kind of statement last within the braces, the construct has type `void', and thus effectively no value.) This feature is especially useful in making macro definitions "safe" (so that they evaluate each operand exactly once). For example, the "maximum" function is commonly defined as a macro in standard C as follows: #define max(a,b) ((a) > (b) ? (a) : (b)) But this definition computes either A or B twice, with bad results if the operand has side effects. In GNU C, if you know the type of the operands (here let's assume `int'), you can define the macro safely as follows: #define maxint(a,b) \ ({int _a = (a), _b = (b); _a > _b ? _a : _b; }) Embedded statements are not allowed in constant expressions, such as the value of an enumeration constant, the width of a bit-field, or the initial value of a static variable. If you don't know the type of the operand, you can still do this, but you must use `typeof' (*note Typeof::). Statement expressions are not supported fully in G++, and their fate there is unclear. (It is possible that they will become fully supported at some point, or that they will be deprecated, or that the bugs that are present will continue to exist indefinitely.) Presently, statement expressions do not work well as default arguments. In addition, there are semantic issues with statement-expressions in C++. If you try to use statement-expressions instead of inline functions in C++, you may be surprised at the way object destruction is handled. For example: #define foo(a) ({int b = (a); b + 3; }) does not work the same way as: inline int foo(int a) { int b = a; return b + 3; } In particular, if the expression passed into `foo' involves the creation of temporaries, the destructors for those temporaries will be run earlier in the case of the macro than in the case of the function. These considerations mean that it is probably a bad idea to use statement-expressions of this form in header files that are designed to work with C++. (Note that some versions of the GNU C Library contained header files using statement-expression that lead to precisely this bug.)