InfoMagic Source Code 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / msdos / djgpp / docs / gcc / gcc.i5 < prev next >

Wrap

GNU Info File | 1993-05-29 | 49.6 KB | 1,227 lines

This is Info file gcc.info, produced by Makeinfo-1.54 from the input file gcc.texi. This file documents the use and the internals of the GNU compiler. Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the sections entitled "GNU General Public License" and "Protect Your Freedom--Fight `Look And Feel'" are included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the sections entitled "GNU General Public License" and "Protect Your Freedom--Fight `Look And Feel'", and this permission notice, may be included in translations approved by the Free Software Foundation instead of in the original English. File: gcc.info, Node: Cross-Compiler, Next: PA Install, Prev: Other Dir, Up: Installation Building and Installing a Cross-Compiler ======================================== GNU CC can function as a cross-compiler for many machines, but not all. * Cross-compilers for the Mips as target do not work because the auxiliary programs `mips-tdump.c' and `mips-tfile.c' can't be compiled on anything but a Mips. * Cross-compilers to or from the Vax probably don't work completely because the Vax uses an incompatible floating point format (not IEEE format). Since GNU CC generates assembler code, you probably need a cross-assembler that GNU CC can run, in order to produce object files. If you want to link on other than the target machine, you need a cross-linker as well. You also need header files and libraries suitable for the target machine that you can install on the host machine. To build GNU CC as a cross-compiler, you start out by running `configure'. You must specify two different configurations, the host and the target. Use the `--host=HOST' option for the host and `--target=TARGET' to specify the target type. For example, here is how to configure for a cross-compiler that runs on a hypothetical Intel 386 system and produces code for an HP 68030 system running BSD: configure --target=m68k-hp-bsd4.3 --host=i386-bozotheclone-bsd4.3 Next you should install the cross-assembler and cross-linker (and `ar' and `ranlib'). Put them in the directory `/usr/local/TARGET/bin'. The installation of GNU CC will find them there and copy or link them to the proper place to find them when you run the cross-compiler later. If you want to install any additional libraries to use with the cross-compiler, put them in the directory `/usr/local/TARGET/lib'; all files in that subdirectory will be installed in the proper place when you install the cross-compiler. Likewise, put the header files for the target machine in `/usr/local/TARGET/include'. You must now produce a substitute for `libgcc1.a'. Normally this file is compiled with the "native compiler" for the target machine; compiling it with GNU CC does not work. But compiling it with the host machine's compiler also doesn't work--that produces a file that would run on the host, and you need it to run on the target. We can't give you any automatic way to produce this substitute. For some targets, the subroutines in `libgcc1.c' are not actually used. You need not provide the ones that won't be used. The ones that most commonly are used are the multiplication, division and remainder routines--many RISC machines rely on the library for this. One way to make them work is to define the appropriate `perform_...' macros for the subroutines that you need. If these definitions do not use the C arithmetic operators that they are meant to implement, you might be able to compile them with the cross-compiler you are building. To do this, specify `LIBGCC1=libgcc1.a OLDCC=./xgcc' when building the compiler. Now you can proceed just as for compiling a single-machine compiler through the step of building stage 1. If you have not provided some sort of `libgcc1.a', then compilation will give up at the point where it needs that file, printing a suitable error message. If you do provide `libgcc1.a', then building the compiler will automatically compile and link a test program called `cross-test'; if you get errors in the linking, it means that not all of the necessary routines in `libgcc1.a' are available. When you are using a cross-compiler configuration, building stage 1 does not compile all of GNU CC. This is because one part of building, the compilation of `libgcc2.c', requires use of the cross-compiler. However, when you type `make install' to install the bulk of the cross-compiler, that will also compile `libgcc2.c' and install the resulting `libgcc.a'. Do not try to build stage 2 for a cross-compiler. It doesn't work to rebuild GNU CC as a cross-compiler using the cross-compiler, because that would produce a program that runs on the target machine, not on the host. For example, if you compile a 386-to-68030 cross-compiler with itself, the result will not be right either for the 386 (because it was compiled into 68030 code) or for the 68030 (because it was configured for a 386 as the host). If you want to compile GNU CC into 68030 code, whether you compile it on a 68030 or with a cross-compiler on a 386, you must specify a 68030 as the host when you configure it. File: gcc.info, Node: PA Install, Next: Sun Install, Prev: Cross-Compiler, Up: Installation GNU CC on the HP Precision Architecture ======================================= There are two variants of this CPU, called 1.0 and 1.1, which have different machine descriptions. You must use the right one for your machine. All 7NN machines and 8N7 machines use 1.1, while all other 8NN machines use 1.0. The easiest way to handle this problem is to use `configure hpNNN' or `configure hpNNN-hpux', where NNN is the model number of the machine. Then `configure' will figure out if the machine is a 1.0 or 1.1. Use `uname -a' to find out the model number of your machine. `-g' does not work on HP-UX, since that system uses a peculiar debugging format which GNU CC does not know about. There are preliminary versions of GAS and GDB for the HP-PA which do work with GNU CC for debugging. You can get them by anonymous ftp from `jaguar.cs.utah.edu' `dist' subdirectory. You would need to install GAS in the file /usr/local/lib/gcc-lib/CONFIGURATION/GCCVERSION/as where CONFIGURATION is the configuration name (perhaps `hpNNN-hpux') and GCCVERSION is the GNU CC version number. Do this *before* starting the build process, otherwise you will get errors from the HPUX assembler while building `libgcc2.a'. The command make install-dir will create the necessary directory hierarchy so you can install GAS before building GCC. If you obtained GAS before October 6, 1992 it is highly recommended you get a new one to avoid several bugs which have been discovered recently. To enable debugging, configure GNU CC with the `--gas' option before building. It has been reported that GNU CC produces invalid assembly code for 1.1 machines running HP-UX 8.02 when using the HP assembler. Typically the errors look like this: as: bug.s @line#15 [err#1060] Argument 0 or 2 in FARG upper - lookahead = ARGW1=FR,RTNVAL=GR as: foo.s @line#28 [err#1060] Argument 0 or 2 in FARG upper - lookahead = ARGW1=FR You can check the version of HP-UX you are running by executing the command `uname -r'. If you are indeed running HP-UX 8.02 on a 1.1 machine and using the HP assembler then configure GCC with "hp700-hpux8.02". File: gcc.info, Node: Sun Install, Next: 3b1 Install, Prev: PA Install, Up: Installation Installing GNU CC on the Sun ============================ Make sure the environment variable `FLOAT_OPTION' is not set when you compile `libgcc.a'. If this option were set to `f68881' when `libgcc.a' is compiled, the resulting code would demand to be linked with a special startup file and would not link properly without special pains. There is a bug in `alloca' in certain versions of the Sun library. To avoid this bug, install the binaries of GNU CC that were compiled by GNU CC. They use `alloca' as a built-in function and never the one in the library. Some versions of the Sun compiler crash when compiling GNU CC. The problem is a segmentation fault in cpp. This problem seems to be due to the bulk of data in the environment variables. You may be able to avoid it by using the following command to compile GNU CC with Sun CC: make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc" File: gcc.info, Node: 3b1 Install, Next: Unos Install, Prev: Sun Install, Up: Installation Installing GNU CC on the 3b1 ============================ Installing GNU CC on the 3b1 is difficult if you do not already have GNU CC running, due to bugs in the installed C compiler. However, the following procedure might work. We are unable to test it. 1. Comment out the `#include "config.h"' line on line 37 of `cccp.c' and do `make cpp'. This makes a preliminary version of GNU cpp. 2. Save the old `/lib/cpp' and copy the preliminary GNU cpp to that file name. 3. Undo your change in `cccp.c', or reinstall the original version, and do `make cpp' again. 4. Copy this final version of GNU cpp into `/lib/cpp'. 5. Replace every occurrence of `obstack_free' in the file `tree.c' with `_obstack_free'. 6. Run `make' to get the first-stage GNU CC. 7. Reinstall the original version of `/lib/cpp'. 8. Now you can compile GNU CC with itself and install it in the normal fashion. File: gcc.info, Node: Unos Install, Next: VMS Install, Prev: 3b1 Install, Up: Installation Installing GNU CC on Unos ========================= Use `configure unos' for building on Unos. The Unos assembler is named `casm' instead of `as'. For some strange reason linking `/bin/as' to `/bin/casm' changes the behavior, and does not work. So, when installing GNU CC, you should install the following script as `as' in the subdirectory where the passes of GCC are installed: #!/bin/sh casm $* The default Unos library is named `libunos.a' instead of `libc.a'. To allow GNU CC to function, either change all references to `-lc' in `gcc.c' to `-lunos' or link `/lib/libc.a' to `/lib/libunos.a'. When compiling GNU CC with the standard compiler, to overcome bugs in the support of `alloca', do not use `-O' when making stage 2. Then use the stage 2 compiler with `-O' to make the stage 3 compiler. This compiler will have the same characteristics as the usual stage 2 compiler on other systems. Use it to make a stage 4 compiler and compare that with stage 3 to verify proper compilation. (Perhaps simply defining `ALLOCA' in `x-crds' as described in the comments there will make the above paragraph superfluous. Please inform us of whether this works.) Unos uses memory segmentation instead of demand paging, so you will need a lot of memory. 5 Mb is barely enough if no other tasks are running. If linking `cc1' fails, try putting the object files into a library and linking from that library. File: gcc.info, Node: VMS Install, Next: WE32K Install, Prev: Unos Install, Up: Installation Installing GNU CC on VMS ======================== The VMS version of GNU CC is distributed in a backup saveset containing both source code and precompiled binaries. To install the `gcc' command so you can use the compiler easily, in the same manner as you use the VMS C compiler, you must install the VMS CLD file for GNU CC as follows: 1. Define the VMS logical names `GNU_CC' and `GNU_CC_INCLUDE' to point to the directories where the GNU CC executables (`gcc-cpp.exe', `gcc-cc1.exe', etc.) and the C include files are kept respectively. This should be done with the commands: $ assign /system /translation=concealed - disk:[gcc.] gnu_cc $ assign /system /translation=concealed - disk:[gcc.include.] gnu_cc_include with the appropriate disk and directory names. These commands can be placed in your system startup file so they will be executed whenever the machine is rebooted. You may, if you choose, do this via the `GCC_INSTALL.COM' script in the `[GCC]' directory. 2. Install the `GCC' command with the command line: $ set command /table=sys$common:[syslib]dcltables - /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc $ install replace sys$common:[syslib]dcltables 3. To install the help file, do the following: $ library/help sys$library:helplib.hlb gcc.hlp Now you can invoke the compiler with a command like `gcc /verbose file.c', which is equivalent to the command `gcc -v -c file.c' in Unix. If you wish to use GNU C++ you must first install GNU CC, and then perform the following steps: 1. Define the VMS logical name `GNU_GXX_INCLUDE' to point to the directory where the preprocessor will search for the C++ header files. This can be done with the command: $ assign /system /translation=concealed - disk:[gcc.gxx_include.] gnu_gxx_include with the appropriate disk and directory name. If you are going to be using libg++, this is where the libg++ install procedure will install the libg++ header files. 2. Obtain the file `gcc-cc1plus.exe', and place this in the same directory that `gcc-cc1.exe' is kept. The GNU C++ compiler can be invoked with a command like `gcc /plus /verbose file.cc', which is equivalent to the command `g++ -v -c file.cc' in Unix. We try to put corresponding binaries and sources on the VMS distribution tape. But sometimes the binaries will be from an older version than the sources, because we don't always have time to update them. (Use the `/version' option to determine the version number of the binaries and compare it with the source file `version.c' to tell whether this is so.) In this case, you should use the binaries you get to recompile the sources. If you must recompile, here is how: 1. Execute the command procedure `vmsconfig.com' to copy files `vax-vms.h', `xm-vax-vms.h', `vax.c' and `vax.md' to files `tm.h', `config.h', `aux-output.c', and `md.' respectively, and to create files `tconfig.h' and `hconfig.h'. This procedure also creates several linker option files used by `make-cc1.com' and a data file used by `make-l2.com'. $ @vmsconfig.com 2. Setup the logical names and command tables as defined above. In addition, define the VMS logical name `GNU_BISON' to point at the to the directories where the Bison executable is kept. This should be done with the command: $ assign /system /translation=concealed - disk:[bison.] gnu_bison You may, if you choose, use the `INSTALL_BISON.COM' script in the `[BISON]' directory. 3. Install the `BISON' command with the command line: $ set command /table=sys$common:[syslib]dcltables - /output=sys$common:[syslib]dcltables - gnu_bison:[000000]bison $ install replace sys$common:[syslib]dcltables 4. Type `@make-gcc' to recompile everything (alternatively, you may submit the file `make-gcc.com' to a batch queue). If you wish to build the GNU C++ compiler as well as the GNU CC compiler, you must first edit `make-gcc.com' and follow the instructions that appear in the comments. 5. In order to use GCC, you need a library of functions which GCC compiled code will call to perform certain tasks, and these functions are defined in the file `libgcc2.c'. To compile this you should use the command procedure `make-l2.com', which will generate the library `libgcc2.olb'. `libgcc2.olb' should be built using the compiler built from the same distribution that `libgcc2.c' came from, and `make-gcc.com' will automatically do all of this for you. To install the library, use the following commands: $ library gnu_cc:[000000]gcclib/delete=(new,eprintf) $ library gnu_cc:[000000]gcclib/delete=L_* $ library libgcc2/extract=*/output=libgcc2.obj $ library gnu_cc:[000000]gcclib libgcc2.obj The first command simply removes old modules that will be replaced with modules from `libgcc2' under different module names. The modules `new' and `eprintf' may not actually be present in your `gcclib.olb'--if the VMS librarian complains about those modules not being present, simply ignore the message and continue on with the next command. The second command removes the modules that came from the previous version of the library `libgcc2.c'. Whenever you update the compiler on your system, you should also update the library with the above procedure. 6. You may wish to build GCC in such a way that no files are written to the directory where the source files reside. An example would be the when the source files are on a read-only disk. In these cases, execute the following DCL commands (substituting your actual path names): $ assign dua0:[gcc.build_dir.]/translation=concealed, - dua1:[gcc.source_dir.]/translation=concealed gcc_build $ set default gcc_build:[000000] where `dua1:[gcc.source_dir]' contains the source code, and `dua0:[gcc.build_dir]' is meant to contain all of the generated object files and executables. Once you have done this, you can proceed building GCC as described above. (Keep in mind that `gcc_build' is a rooted logical name, and thus the device names in each element of the search list must be an actual physical device name rather than another rooted logical name). 7. *If you are building GNU CC with a previous version of GNU CC, you also should check to see that you have the newest version of the assembler*. In particular, GNU CC version 2 treats global constant variables slightly differently from GNU CC version 1, and GAS version 1.38.1 does not have the patches required to work with GCC version 2. If you use GAS 1.38.1, then `extern const' variables will not have the read-only bit set, and the linker will generate warning messages about mismatched psect attributes for these variables. These warning messages are merely a nuisance, and can safely be ignored. If you are compiling with a version of GNU CC older than 1.33, specify `/DEFINE=("inline=")' as an option in all the compilations. This requires editing all the `gcc' commands in `make-cc1.com'. (The older versions had problems supporting `inline'.) Once you have a working 1.33 or newer GNU CC, you can change this file back. 8. If you want to build GNU CC with the VAX C compiler, you will need to make minor changes in `make-cccp.com' and `make-cc1.com' to choose alternate definitions of `CC', `CFLAGS', and `LIBS'. See comments in those files. However, you must also have a working version of the GNU assembler (GNU as, aka GAS) as it is used as the back-end for GNU CC to produce binary object modules and is not included in the GNU CC sources. GAS is also needed to compile `libgcc2' in order to build `gcclib' (see above); `make-l2.com' expects to be able to find it operational in `gnu_cc:[000000]gnu-as.exe'. To use GNU CC on VMS, you need the VMS driver programs `gcc.exe', `gcc.com', and `gcc.cld'. They are distributed with the VMS binaries (`gcc-vms') rather than the GNU CC sources. GAS is also included in `gcc-vms', as is Bison. Once you have successfully built GNU CC with VAX C, you should use the resulting compiler to rebuild itself. Before doing this, be sure to restore the `CC', `CFLAGS', and `LIBS' definitions in `make-cccp.com' and `make-cc1.com'. The second generation compiler will be able to take advantage of many optimizations that must be suppressed when building with other compilers. Under previous versions of GNU CC, the generated code would occasionally give strange results when linked with the sharable `VAXCRTL' library. Now this should work. Even with this version, however, GNU CC itself should not be linked with the sharable `VAXCRTL'. The version of `qsort' in `VAXCRTL' has a bug (known to be present in VMS versions V4.6 through V5.5) which causes the compiler to fail. The executables are generated by `make-cc1.com' and `make-cccp.com' use the object library version of `VAXCRTL' in order to make use of the `qsort' routine in `gcclib.olb'. If you wish to link the compiler executables with the shareable image version of `VAXCRTL', you should edit the file `tm.h' (created by `vmsconfig.com') to define the macro `QSORT_WORKAROUND'. `QSORT_WORKAROUND' is always defined when GNU CC is compiled with VAX C, to avoid a problem in case `gcclib.olb' is not yet available. File: gcc.info, Node: WE32K Install, Next: MIPS Install, Prev: VMS Install, Up: Installation Installing GNU CC on the WE32K ============================== These computers are also known as the 3b2, 3b5, 3b20 and other similar names. (However, the 3b1 is actually a 68000; see *Note 3b1 Install::.) Don't use `-g' when compiling with the system's compiler. The system's linker seems to be unable to handle such a large program with debugging information. The system's compiler runs out of capacity when compiling `stmt.c' in GNU CC. You can work around this by building `cpp' in GNU CC first, then use that instead of the system's preprocessor with the system's C compiler to compile `stmt.c'. Here is how: mv /lib/cpp /lib/cpp.att cp cpp /lib/cpp.gnu echo "/lib/cpp.gnu -traditional $*" > /lib/cpp chmod +x /lib/cpp The system's compiler produces bad code for some of the GNU CC optimization files. So you must build the stage 2 compiler without optimization. Then build a stage 3 compiler with optimization. That executable should work. Here are the necessary commands: make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g" make stage2 make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O" You may need to raise the ULIMIT setting to build a C++ compiler, as the file `cc1plus' is larger than one megabyte. File: gcc.info, Node: MIPS Install, Next: Collect2, Prev: WE32K Install, Up: Installation Installing GNU CC on the MIPS ============================= See *Note Installation:: about whether to use either of the options `--with-stabs' or `--with-gnu-as'. The MIPS C compiler needs to be told to increase its table size for switch statements with the `-Wf,-XNg1500' option in order to compile `cp-parse.c'. If you use the `-O2' optimization option, you also need to use `-Olimit 3000'. Both of these options are automatically generated in the `Makefile' that the shell script `configure' builds. If you override the `CC' make variable and use the MIPS compilers, you may need to add `-Wf,-XNg1500 -Olimit 3000'. MIPS computers running RISC-OS can support four different personalities: default, BSD 4.3, System V.3, and System V.4 (older versions of RISC-OS don't support V.4). To configure GCC for these platforms use the following configurations: `mips-mips-riscos`rev'' Default configuration for RISC-OS, revision `rev'. `mips-mips-riscos`rev'bsd' BSD 4.3 configuration for RISC-OS, revision `rev'. `mips-mips-riscos`rev'sysv4' System V.4 configuration for RISC-OS, revision `rev'. `mips-mips-riscos`rev'sysv' System V.3 configuration for RISC-OS, revision `rev'. The revision `rev' mentioned above is the revision of RISC-OS to use. You must reconfigure GCC when going from a RISC-OS revision 4 to RISC-OS revision 5. This has the effect of avoiding a linker bug (see *Note Installation Problems:: for more details). DECstations can support three different personalities: Ultrix, DEC OSF/1, and OSF/rose. To configure GCC for these platforms use the following configurations: `decstation-ultrix' Ultrix configuration. `decstation-osf1' Dec's version of OSF/1. `decstation-osfrose' Open Software Foundation reference port of OSF/1 which uses the OSF/rose object file format instead of ECOFF. Normally, you would not select this configuration. On Irix version 4.0.5F, and perhaps on some other versions as well, there is an assembler bug that reorders instructions incorrectly. To work around it, specify the target configuration `mips-sgi-irix4loser'. This configuration inhibits assembler optimization. You can turn off assembler optimization in a compiler configured with target `mips-sgi-irix4' using the `-noasmopt' option. This compiler option passes the option `-O0' to the assembler, to inhibit reordering. The `-noasmopt' option can be useful for testing whether a problem is due to erroneous assembler reordering. Even if a problem does not go away with `-noasmopt', it may still be due to assembler reordering--perhaps GNU CC itself was miscompiled as a result. We know this is inconvenient, but it's the best that can be done at the last minute. File: gcc.info, Node: Collect2, Prev: MIPS Install, Up: Installation `collect2' ========== Many target systems do not have support in the assembler and linker for "constructors"--initialization functions to be called before the official "start" of `main'. On such systems, GNU CC uses a utility called `collect2' to arrange to call these functions at start time. The program `collect2' works by linking the program once and looking through the linker output file for symbols with particular names indicating they are constructor functions. If it finds any, it creates a new temporary `.c' file containing a table of them, compiles it, and links the program a second time including that file. The actual calls to the constructors are carried out by a subroutine called `__main', which is called (automatically) at the beginning of the body of `main' (provided `main' was compiled with GNU CC). The program `collect2' is installed as `ld' in the directory where the passes of the compiler are installed. When `collect2' needs to find the *real* `ld', it tries the following file names: * `gld' in the directories listed in the compiler's search directories. * `gld' in the directories listed in the environment variable `PATH'. * `real-ld' in the compiler's search directories. * `real-ld' in `PATH'. * `ld' in `PATH'. "The compiler's search directories" means all the directories where `gcc' searches for passes of the compiler. This includes directories that you specify with `-B'. Cross compilers search a little differently: * `gld' in the compiler's search directories. * `TARGET-gld' in `PATH'. * `real-ld' in the compiler's search directories. * `TARGET-real-ld' in `PATH'. * `TARGET-ld' in `PATH'. `collect2' does not search for `ld' using the compiler's search directories, because if it did, it would find itself--not the real `ld'--and this could lead to infinite recursion. However, the directory where `collect2' is installed might happen to be in `PATH'. That could lead `collect2' to invoke itself anyway. when looking for `ld'. To prevent this, `collect2' explicitly avoids running `ld' using the file name under which `collect2' itself was invoked. In fact, it remembers up to two such names--in case one copy of `collect2' finds another copy (or version) of `collect2' installed as `ld' in a second place in the search path. If two file names to avoid are not sufficient, you may still encounter an infinite recursion of `collect2' processes. When this happens. check all the files installed as `ld' in any of the directories searched, and straighten out the situation. (In a future version, we will probably change `collect2' to avoid any reinvocation of a file from which any parent `collect2' was run.) File: gcc.info, Node: C Extensions, Next: C++ Extensions, Prev: Installation, Up: Top Extensions to the C Language Family *********************************** GNU C provides several language features not found in ANSI standard C. (The `-pedantic' option directs GNU CC 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 GNU CC. These extensions are available in C and in the languages derived from it, C++ and Objective C. *Note Extensions to the C++ Language: C++ Extensions, for extensions that apply *only* to 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. * Naming Types:: Giving a name to the type of some expression. * 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'. * Zero Length:: Zero-length arrays. * Variable Length:: Arrays whose length is computed at run time. * Macro Varargs:: Macros with variable number of arguments. * Subscripting:: Any array can be subscripted, even if not an lvalue. * Pointer Arith:: Arithmetic on `void'-pointers and function pointers. * Initializers:: Non-constant initializers. * Constructors:: Constructor expressions give structures, unions or arrays as values. * Labeled Elements:: Labeling elements of initializers. * Cast to Union:: Casting to union type from any member of the union. * Case Ranges:: `case 1 ... 9' and such. * Function Attributes:: Declaring that functions have no side effects, or that they can never return. * Function Prototypes:: Prototype declarations and old-style definitions. * Dollar Signs:: Dollar sign is allowed in identifiers. * Character Escapes:: `\e' stands for the character ESC. * Variable Attributes:: Specifying attributes of variables. * 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.) * 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. 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::.) or type naming (*note Naming Types::.). File: gcc.info, Node: Local Labels, Next: Labels as Values, Prev: Statement Exprs, Up: C Extensions Locally Declared Labels ======================= Each statement expression is a scope in which "local labels" can be declared. A local label is simply an identifier; you can jump to it with an ordinary `goto' statement, but only from within the statement expression it belongs to. A local label declaration looks like this: __label__ LABEL; or __label__ LABEL1, LABEL2, ...; Local label declarations must come at the beginning of the statement expression, right after the `({', before any ordinary declarations. The label declaration defines the label *name*, but does not define the label itself. You must do this in the usual way, with `LABEL:', within the statements of the statement expression. The local label feature is useful because statement expressions are often used in macros. If the macro contains nested loops, a `goto' can be useful for breaking out of them. However, an ordinary label whose scope is the whole function cannot be used: if the macro can be expanded several times in one function, the label will be multiply defined in that function. A local label avoids this problem. For example: #define SEARCH(array, target) \ ({ \ __label__ found; \ typeof (target) _SEARCH_target = (target); \ typeof (*(array)) *_SEARCH_array = (array); \ int i, j; \ int value; \ for (i = 0; i < max; i++) \ for (j = 0; j < max; j++) \ if (_SEARCH_array[i][j] == _SEARCH_target) \ { value = i; goto found; } \ value = -1; \ found: \ value; \ }) File: gcc.info, Node: Labels as Values, Next: Nested Functions, Prev: Local Labels, Up: C Extensions Labels as Values ================ You can get the address of a label defined in the current function (or a containing function) with the unary operator `&&'. The value has type `void *'. This value is a constant and can be used wherever a constant of that type is valid. For example: void *ptr; ... ptr = &&foo; To use these values, you need to be able to jump to one. This is done with the computed goto statement(1), `goto *EXP;'. For example, goto *ptr; Any expression of type `void *' is allowed. One way of using these constants is in initializing a static array that will serve as a jump table: static void *array[] = { &&foo, &&bar, &&hack }; Then you can select a label with indexing, like this: goto *array[i]; Note that this does not check whether the subscript is in bounds--array indexing in C never does that. Such an array of label values serves a purpose much like that of the `switch' statement. The `switch' statement is cleaner, so use that rather than an array unless the problem does not fit a `switch' statement very well. Another use of label values is in an interpreter for threaded code. The labels within the interpreter function can be stored in the threaded code for super-fast dispatching. You can use this mechanism to jump to code in a different function. If you do that, totally unpredictable things will happen. The best way to avoid this is to store the label address only in automatic variables and never pass it as an argument. ---------- Footnotes ---------- (1) The analogous feature in Fortran is called an assigned goto, but that name seems inappropriate in C, where one can do more than simply store label addresses in label variables. File: gcc.info, Node: Nested Functions, Next: Constructing Calls, Prev: Labels as Values, Up: C Extensions Nested Functions ================ A "nested function" is a function defined inside another function. (Nested functions are not supported for GNU C++.) The nested function's name is local to the block where it is defined. For example, here we define a nested function named `square', and call it twice: foo (double a, double b) { double square (double z) { return z * z; } return square (a) + square (b); } The nested function can access all the variables of the containing function that are visible at the point of its definition. This is called "lexical scoping". For example, here we show a nested function which uses an inherited variable named `offset': bar (int *array, int offset, int size) { int access (int *array, int index) { return array[index + offset]; } int i; ... for (i = 0; i < size; i++) ... access (array, i) ... } Nested function definitions must appear in the same part of a function as variable definitions; that is, before the first line of code in the enclosing function. It is possible to call the nested function from outside the scope of its name by storing its address or passing the address to another function: hack (int *array, int size) { void store (int index, int value) { array[index] = value; } intermediate (store, size); } Here, the function `intermediate' receives the address of `store' as an argument. If `intermediate' calls `store', the arguments given to `store' are used to store into `array'. But this technique works only so long as the containing function (`hack', in this example) does not exit. If you try to call the nested function through its address after the containing function has exited, all hell will break loose. GNU CC implements taking the address of a nested function using a technique called "trampolines". A paper describing them is available from `maya.idiap.ch' in the file `pub/tmb/usenix88-lexic.ps.Z'. A nested function can jump to a label inherited from a containing function, provided the label was explicitly declared in the containing function (*note Local Labels::.). Such a jump returns instantly to the containing function, exiting the nested function which did the `goto' and any intermediate functions as well. Here is an example: bar (int *array, int offset, int size) { __label__ failure; int access (int *array, int index) { if (index > size) goto failure; return array[index + offset]; } int i; ... for (i = 0; i < size; i++) ... access (array, i) ... ... return 0; /* Control comes here from `access' if it detects an error. */ failure: return -1; } A nested function always has internal linkage. Declaring one with `extern' is erroneous. If you need to declare the nested function before its definition, use `auto' (which is otherwise meaningless for function declarations). bar (int *array, int offset, int size) { __label__ failure; auto int access (int *, int); ... int access (int *array, int index) { if (index > size) goto failure; return array[index + offset]; } ... } File: gcc.info, Node: Constructing Calls, Next: Naming Types, Prev: Nested Functions, Up: C Extensions Constructing Function Calls =========================== Using the built-in functions described below, you can record the arguments a function received, and call another function with the same arguments, without knowing the number or types of the arguments. You can also record the return value of that function call, and later return that value, without knowing what data type the function tried to return (as long as your caller expects that data type). `__builtin_apply_args ()' This built-in function returns a pointer of type `void *' to data describing how to perform a call with the same arguments as were passed to the current function. The function saves the arg pointer register, structure value address, and all registers that might be used to pass arguments to a function into a block of memory allocated on the stack. Then it returns the address of that block. `__builtin_apply (FUNCTION, ARGUMENTS, SIZE)' This built-in function invokes FUNCTION (type `void (*)()') with a copy of the parameters described by ARGUMENTS (type `void *') and SIZE (type `int'). The value of ARGUMENTS should be the value returned by `__builtin_apply_args'. The argument SIZE specifies the size of the stack argument data, in bytes. This function returns a pointer of type `void *' to data describing how to return whatever value was returned by FUNCTION. The data is saved in a block of memory allocated on the stack. It is not always simple to compute the proper value for SIZE. The value is used by `__builtin_apply' to compute the amount of data that should be pushed on the stack and copied from the incoming argument area. `__builtin_return (RESULT)' This built-in function returns the value described by RESULT from the containing function. You should specify, for RESULT, a value returned by `__builtin_apply'. File: gcc.info, Node: Naming Types, Next: Typeof, Prev: Constructing Calls, Up: C Extensions Naming an Expression's Type =========================== You can give a name to the type of an expression using a `typedef' declaration with an initializer. Here is how to define NAME as a type name for the type of EXP: typedef NAME = EXP; This is useful in conjunction with the statements-within-expressions feature. Here is how the two together can be used to define a safe "maximum" macro that operates on any arithmetic type: #define max(a,b) \ ({typedef _ta = (a), _tb = (b); \ _ta _a = (a); _tb _b = (b); \ _a > _b ? _a : _b; }) The reason for using names that start with underscores for the local variables is to avoid conflicts with variable names that occur within the expressions that are substituted for `a' and `b'. Eventually we hope to design a new form of declaration syntax that allows you to declare variables whose scopes start only after their initializers; this will be a more reliable way to prevent such conflicts. File: gcc.info, Node: Typeof, Next: Lvalues, Prev: Naming Types, Up: C Extensions Referring to a Type with `typeof' ================================= Another way to refer to the type of an expression is with `typeof'. The syntax of using of this keyword looks like `sizeof', but the construct acts semantically like a type name defined with `typedef'. There are two ways of writing the argument to `typeof': with an expression or with a type. Here is an example with an expression: typeof (x[0](1)) This assumes that `x' is an array of functions; the type described is that of the values of the functions. Here is an example with a typename as the argument: typeof (int *) Here the type described is that of pointers to `int'. If you are writing a header file that must work when included in ANSI C programs, write `__typeof__' instead of `typeof'. *Note Alternate Keywords::. A `typeof'-construct can be used anywhere a typedef name could be used. For example, you can use it in a declaration, in a cast, or inside of `sizeof' or `typeof'. * This declares `y' with the type of what `x' points to. typeof (*x) y; * This declares `y' as an array of such values. typeof (*x) y[4]; * This declares `y' as an array of pointers to characters: typeof (typeof (char *)[4]) y; It is equivalent to the following traditional C declaration: char *y[4]; To see the meaning of the declaration using `typeof', and why it might be a useful way to write, let's rewrite it with these macros: #define pointer(T) typeof(T *) #define array(T, N) typeof(T [N]) Now the declaration can be rewritten this way: array (pointer (char), 4) y; Thus, `array (pointer (char), 4)' is the type of arrays of 4 pointers to `char'. File: gcc.info, Node: Lvalues, Next: Conditionals, Prev: Typeof, Up: C Extensions Generalized Lvalues =================== Compound expressions, conditional expressions and casts are allowed as lvalues provided their operands are lvalues. This means that you can take their addresses or store values into them. For example, a compound expression can be assigned, provided the last expression in the sequence is an lvalue. These two expressions are equivalent: (a, b) += 5 a, (b += 5) Similarly, the address of the compound expression can be taken. These two expressions are equivalent: &(a, b) a, &b A conditional expression is a valid lvalue if its type is not void and the true and false branches are both valid lvalues. For example, these two expressions are equivalent: (a ? b : c) = 5 (a ? b = 5 : (c = 5)) A cast is a valid lvalue if its operand is an lvalue. A simple assignment whose left-hand side is a cast works by converting the right-hand side first to the specified type, then to the type of the inner left-hand side expression. After this is stored, the value is converted back to the specified type to become the value of the assignment. Thus, if `a' has type `char *', the following two expressions are equivalent: (int)a = 5 (int)(a = (char *)(int)5) An assignment-with-arithmetic operation such as `+=' applied to a cast performs the arithmetic using the type resulting from the cast, and then continues as in the previous case. Therefore, these two expressions are equivalent: (int)a += 5 (int)(a = (char *)(int) ((int)a + 5)) You cannot take the address of an lvalue cast, because the use of its address would not work out coherently. Suppose that `&(int)f' were permitted, where `f' has type `float'. Then the following statement would try to store an integer bit-pattern where a floating point number belongs: *&(int)f = 1; This is quite different from what `(int)f = 1' would do--that would convert 1 to floating point and store it. Rather than cause this inconsistency, we think it is better to prohibit use of `&' on a cast. If you really do want an `int *' pointer with the address of `f', you can simply write `(int *)&f'. File: gcc.info, Node: Conditionals, Next: Long Long, Prev: Lvalues, Up: C Extensions Conditionals with Omitted Operands ================================== The middle operand in a conditional expression may be omitted. Then if the first operand is nonzero, its value is the value of the conditional expression. Therefore, the expression x ? : y has the value of `x' if that is nonzero; otherwise, the value of `y'. This example is perfectly equivalent to x ? x : y In this simple case, the ability to omit the middle operand is not especially useful. When it becomes useful is when the first operand does, or may (if it is a macro argument), contain a side effect. Then repeating the operand in the middle would perform the side effect twice. Omitting the middle operand uses the value already computed without the undesirable effects of recomputing it. File: gcc.info, Node: Long Long, Next: Zero Length, Prev: Conditionals, Up: C Extensions Double-Word Integers ==================== GNU C supports data types for integers that are twice as long as `long int'. Simply write `long long int' for a signed integer, or `unsigned long long int' for an unsigned integer. To make an integer constant of type `long long int', add the suffix `LL' to the integer. To make an integer constant of type `unsigned long long int', add the suffix `ULL' to the integer. You can use these types in arithmetic like any other integer types. Addition, subtraction, and bitwise boolean operations on these types are open-coded on all types of machines. Multiplication is open-coded if the machine supports fullword-to-doubleword a widening multiply instruction. Division and shifts are open-coded only on machines that provide special support. The operations that are not open-coded use special library routines that come with GNU CC. There may be pitfalls when you use `long long' types for function arguments, unless you declare function prototypes. If a function expects type `int' for its argument, and you pass a value of type `long long int', confusion will result because the caller and the subroutine will disagree about the number of bytes for the argument. Likewise, if the function expects `long long int' and you pass `int'. The best way to avoid such problems is to use prototypes.