This is Info file gcc.info, produced by Makeinfo-1.55 from the input file gcc.texi. This file documents the use and the internals of the GNU compiler. Published by the Free Software Foundation 675 Massachusetts Avenue Cambridge, MA 02139 USA 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 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: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars Specifying Registers for Local Variables ---------------------------------------- You can define a local register variable with a specified register like this: register int *foo asm ("a5"); Here `a5' is the name of the register which should be used. Note that this is the same syntax used for defining global register variables, but for a local variable it would appear within a function. Naturally the register name is cpu-dependent, but this is not a problem, since specific registers are most often useful with explicit assembler instructions (*note Extended Asm::.). Both of these things generally require that you conditionalize your program according to cpu type. In addition, operating systems on one type of cpu may differ in how they name the registers; then you would need additional conditionals. For example, some 68000 operating systems call this register `%a5'. Eventually there may be a way of asking the compiler to choose a register automatically, but first we need to figure out how it should choose and how to enable you to guide the choice. No solution is evident. Defining such a register variable does not reserve the register; it remains available for other uses in places where flow control determines the variable's value is not live. However, these registers are made unavailable for use in the reload pass. I would not be surprised if excessive use of this feature leaves the compiler too few available registers to compile certain functions. File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions Alternate Keywords ================== The option `-traditional' disables certain keywords; `-ansi' disables certain others. This causes trouble when you want to use GNU C extensions, or ANSI C features, in a general-purpose header file that should be usable by all programs, including ANSI C programs and traditional ones. The keywords `asm', `typeof' and `inline' cannot be used since they won't work in a program compiled with `-ansi', while the keywords `const', `volatile', `signed', `typeof' and `inline' won't work in a program compiled with `-traditional'. The way to solve these problems is to put `__' at the beginning and end of each problematical keyword. For example, use `__asm__' instead of `asm', `__const__' instead of `const', and `__inline__' instead of `inline'. Other C compilers won't accept these alternative keywords; if you want to compile with another compiler, you can define the alternate keywords as macros to replace them with the customary keywords. It looks like this: #ifndef __GNUC__ #define __asm__ asm #endif `-pedantic' causes warnings for many GNU C extensions. You can prevent such warnings within one expression by writing `__extension__' before the expression. `__extension__' has no effect aside from this. File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions Incomplete `enum' Types ======================= You can define an `enum' tag without specifying its possible values. This results in an incomplete type, much like what you get if you write `struct foo' without describing the elements. A later declaration which does specify the possible values completes the type. You can't allocate variables or storage using the type while it is incomplete. However, you can work with pointers to that type. This extension may not be very useful, but it makes the handling of `enum' more consistent with the way `struct' and `union' are handled. File: gcc.info, Node: Function Names, Prev: Incomplete Enums, Up: C Extensions Function Names as Strings ========================= GNU CC predefines two string variables to be the name of the current function. The variable `__FUNCTION__' is the name of the function as it appears in the source. The variable `__PRETTY_FUNCTION__' is the name of the function pretty printed in a language specific fashion. These names are always the same in a C function, but in a C++ function they may be different. For example, this program: extern "C" { extern int printf (char *, ...); } class a { public: sub (int i) { printf ("__FUNCTION__ = %s\n", __FUNCTION__); printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__); } }; int main (void) { a ax; ax.sub (0); return 0; } gives this output: __FUNCTION__ = sub __PRETTY_FUNCTION__ = int a::sub (int) File: gcc.info, Node: C++ Extensions, Next: Trouble, Prev: C Extensions, Up: Top Extensions to the C++ Language ****************************** The GNU compiler provides these extensions to the C++ language (and you can also use most of the C language extensions in your C++ programs). If you want to write code that checks whether these features are available, you can test for the GNU compiler the same way as for C programs: check for a predefined macro `__GNUC__'. You can also use `__GNUG__' to test specifically for GNU C++ (*note Standard Predefined Macros: (cpp.info)Standard Predefined.). * Menu: * Naming Results:: Giving a name to C++ function return values. * Min and Max:: C++ Minimum and maximum operators. * Destructors and Goto:: Goto is safe to use in C++ even when destructors are needed. * C++ Interface:: You can use a single C++ header file for both declarations and definitions. File: gcc.info, Node: Naming Results, Next: Min and Max, Up: C++ Extensions Named Return Values in C++ ========================== GNU C++ extends the function-definition syntax to allow you to specify a name for the result of a function outside the body of the definition, in C++ programs: TYPE FUNCTIONNAME (ARGS) return RESULTNAME; { ... BODY ... } You can use this feature to avoid an extra constructor call when a function result has a class type. For example, consider a function `m', declared as `X v = m ();', whose result is of class `X': X m () { X b; b.a = 23; return b; } Although `m' appears to have no arguments, in fact it has one implicit argument: the address of the return value. At invocation, the address of enough space to hold `v' is sent in as the implicit argument. Then `b' is constructed and its `a' field is set to the value 23. Finally, a copy constructor (a constructor of the form `X(X&)') is applied to `b', with the (implicit) return value location as the target, so that `v' is now bound to the return value. But this is wasteful. The local `b' is declared just to hold something that will be copied right out. While a compiler that combined an "elision" algorithm with interprocedural data flow analysis could conceivably eliminate all of this, it is much more practical to allow you to assist the compiler in generating efficient code by manipulating the return value explicitly, thus avoiding the local variable and copy constructor altogether. Using the extended GNU C++ function-definition syntax, you can avoid the temporary allocation and copying by naming `r' as your return value as the outset, and assigning to its `a' field directly: X m () return r; { r.a = 23; } The declaration of `r' is a standard, proper declaration, whose effects are executed *before* any of the body of `m'. Functions of this type impose no additional restrictions; in particular, you can execute `return' statements, or return implicitly by reaching the end of the function body ("falling off the edge"). Cases X m () return r (23); { return; } (or even `X m () return r (23); { }') are unambiguous, since the return value `r' has been initialized in either case. The following code may be hard to read, but also works predictably: X m () return r; { X b; return b; } The return value slot denoted by `r' is initialized at the outset, but the statement `return b;' overrides this value. The compiler deals with this by destroying `r' (calling the destructor if there is one, or doing nothing if there is not), and then reinitializing `r' with `b'. This extension is provided primarily to help people who use overloaded operators, where there is a great need to control not just the arguments, but the return values of functions. For classes where the copy constructor incurs a heavy performance penalty (especially in the common case where there is a quick default constructor), this is a major savings. The disadvantage of this extension is that you do not control when the default constructor for the return value is called: it is always called at the beginning. File: gcc.info, Node: Min and Max, Next: Destructors and Goto, Prev: Naming Results, Up: C++ Extensions Minimum and Maximum Operators in C++ ==================================== It is very convenient to have operators which return the "minimum" or the "maximum" of two arguments. In GNU C++ (but not in GNU C), `A ? B' is the "maximum", returning the larger of the numeric values A and B. These operations are not primitive in ordinary C++, since you can use a macro to return the minimum of two things in C++, as in the following example. #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y)) You might then use `int min = MIN (i, j);' to set MIN to the minimum value of variables I and J. However, side effects in `X' or `Y' may cause unintended behavior. For example, `MIN (i++, j++)' will fail, incrementing the smaller counter twice. A GNU C extension allows you to write safe macros that avoid this kind of problem (*note Naming an Expression's Type: Naming Types.). However, writing `MIN' and `MAX' as macros also forces you to use function-call notation notation for a fundamental arithmetic operation. Using GNU C++ extensions, you can write `int min = i ?' are built into the compiler, they properly handle expressions with side-effects; `int min = i++ insert the line #if __PGC__ and after the lines extern int vprintf(const char *, va_list ); extern int vsprintf(char *, const char *, va_list ); #endif insert the line #endif /* __PGC__ */ These problems don't exist in operating system version 1.1. * On the Altos 3068, programs compiled with GNU CC won't work unless you fix a kernel bug. This happens using system versions V.2.2 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the file `README.ALTOS'. * You will get several sorts of compilation and linking errors on the we32k if you don't follow the special instructions. *Note WE32K Install::. File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble Cross-Compiler Problems ======================= You may run into problems with cross compilation on certain machines, for several reasons. * Cross compilation can run into trouble for certain machines because some target machines' assemblers require floating point numbers to be written as *integer* constants in certain contexts. The compiler writes these integer constants by examining the floating point value as an integer and printing that integer, because this is simple to write and independent of the details of the floating point representation. But this does not work if the compiler is running on a different machine with an incompatible floating point format, or even a different byte-ordering. In addition, correct constant folding of floating point values requires representing them in the target machine's format. (The C standard does not quite require this, but in practice it is the only way to win.) It is now possible to overcome these problems by defining macros such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of work for each target machine. *Note Cross-compilation::. * At present, the program `mips-tfile' which adds debug support to object files on MIPS systems does not work in a cross compile environment. File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble Interoperation ============== This section lists various difficulties encountered in using GNU C or GNU C++ together with other compilers or with the assemblers, linkers, libraries and debuggers on certain systems. * Objective C does not work on the RS/6000 or the Alpha. * C++ does not work on the Alpha. * GNU C++ does not do name mangling in the same way as other C++ compilers. This means that object files compiled with one compiler cannot be used with another. This effect is intentional, to protect you from more subtle problems. Compilers differ as to many internal details of C++ implementation, including: how class instances are laid out, how multiple inheritance is implemented, and how virtual function calls are handled. If the name encoding were made the same, your programs would link against libraries provided from other compilers--but the programs would then crash when run. Incompatible libraries are then detected at link time, rather than at run time. * Older GDB versions sometimes fail to read the output of GNU CC version 2. If you have trouble, get GDB version 4.4 or later. * DBX rejects some files produced by GNU CC, though it accepts similar constructs in output from PCC. Until someone can supply a coherent description of what is valid DBX input and what is not, there is nothing I can do about these problems. You are on your own. * The GNU assembler (GAS) does not support PIC. To generate PIC code, you must use some other assembler, such as `/bin/as'. * On some BSD systems, including some versions of Ultrix, use of profiling causes static variable destructors (currently used only in C++) not to be run. * Use of `-I/usr/include' may cause trouble. Many systems come with header files that won't work with GNU CC unless corrected by `fixincludes'. The corrected header files go in a new directory; GNU CC searches this directory before `/usr/include'. If you use `-I/usr/include', this tells GNU CC to search `/usr/include' earlier on, before the corrected headers. The result is that you get the uncorrected header files. Instead, you should use these options (when compiling C programs): -I/gnu/lib/gcc-lib/TARGET/VERSION/include -I/usr/include For C++ programs, GNU CC also uses a special directory that defines C++ interfaces to standard C subroutines. This directory is meant to be searched *before* other standard include directories, so that it takes precedence. If you are compiling C++ programs and specifying include directories explicitly, use this option first, then the two options above: -I/gnu/lib/g++-include * On some SGI systems, when you use `-lgl_s' as an option, it gets translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this does not happen when you use GNU CC. You must specify all three options explicitly. * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte boundary, and it expects every `double' to be so aligned. The Sun compiler usually gives `double' values 8-byte alignment, with one exception: function arguments of type `double' may not be aligned. As a result, if a function compiled with Sun CC takes the address of an argument of type `double' and passes this pointer of type `double *' to a function compiled with GNU CC, dereferencing the pointer may cause a fatal signal. One way to solve this problem is to compile your entire program with GNU CC. Another solution is to modify the function that is compiled with Sun CC to copy the argument into a local variable; local variables are always properly aligned. A third solution is to modify the function that uses the pointer to dereference it via the following function `access_double' instead of directly with `*': inline double access_double (double *unaligned_ptr) { union d2i { double d; int i[2]; }; union d2i *p = (union d2i *) unaligned_ptr; union d2i u; u.i[0] = p->i[0]; u.i[1] = p->i[1]; return u.d; } Storing into the pointer can be done likewise with the same union. * On Solaris, the `malloc' function in the `libmalloc.a' library may allocate memory that is only 4 byte aligned. Since GNU CC on the Sparc assumes that doubles are 8 byte aligned, this may result in a fatal signal if doubles are stored in memory allocated by the `libmalloc.a' library. The solution is to not use the `libmalloc.a' library. Use instead `malloc' and related functions from `libc.a'; they do not have this problem. * On a Sun, linking using GNU CC fails to find a shared library and reports that the library doesn't exist at all. This happens if you are using the GNU linker, because it does only static linking and looks only for unshared libraries. If you have a shared library with no unshared counterpart, the GNU linker won't find anything. We hope to make a linker which supports Sun shared libraries, but please don't ask when it will be finished--we don't know. * Sun forgot to include a static version of `libdl.a' with some versions of SunOS (mainly 4.1). This results in undefined symbols when linking static binaries (that is, if you use `-static'). If you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when linking, compile and link against the file `mit/util/misc/dlsym.c' from the MIT version of X windows. * The 128-bit long double format that the Sparc port supports currently works by using the architecturally defined quad-word floating point instructions. Since there is no hardware that supports these instructions they must be emulated by the operating system. Long doubles do not work in Sun OS versions 4.0.3 and earlier, because the kernel eumulator uses an obsolete and incompatible format. Long doubles do not work in Sun OS versions 4.1.1 to 4.1.3 because of emululator bugs that cause random unpredicatable failures. Long doubles appear to work in Sun OS 5.x (Solaris 2.x). A future implementation of the sparc long double support will use functions calls to library routines instead of the quad-word floating point instructions. This will allow long doubles to work in more situtations, since one can then substitute a working library if the kernel emulator is buggy. * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not compile GNU CC correctly. We do not yet know why. However, GNU CC compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can compile itself properly on 9.01. * On the HP PA machine, ADB sometimes fails to work on functions compiled with GNU CC. Specifically, it fails to work on functions that use `alloca' or variable-size arrays. This is because GNU CC doesn't generate HP-UX unwind descriptors for such functions. It may even be impossible to generate them. * Debugging (`-g') is not supported on the HP PA machine, unless you use the preliminary GNU tools (*note Installation::.). * Taking the address of a label may generate errors from the HP-UX PA assembler. GAS for the PA does not have this problem. * Using floating point parameters for indirect calls to static functions will not work when using the HP assembler. There simply is no way for GCC to specify what registers hold arguments for static functions when using the HP assembler. GAS for the PA does not have this problem. * For some very large functions you may receive errors from the HP linker complaining about an out of bounds unconditional branch offset. Fixing this problem correctly requires fixing problems in GNU CC and GAS. We hope to fix this in time for GNU CC 2.6. Until then you can work around by making your function smaller, and if you are using GAS, splitting the function into multiple source files may be necessary. * GNU CC compiled code sometimes emits warnings from the HP-UX assembler of the form: (warning) Use of GR3 when frame >= 8192 may cause conflict. These warnings are harmless and can be safely ignored. * The current version of the assembler (`/bin/as') for the RS/6000 has certain problems that prevent the `-g' option in GCC from working. Note that `Makefile.in' uses `-g' by default when compiling `libgcc2.c'. IBM has produced a fixed version of the assembler. The upgraded assembler unfortunately was not included in any of the AIX 3.2 update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 should request PTF U403044 from IBM and users of AIX 3.2 should request PTF U416277. See the file `README.RS6000' for more details on these updates. You can test for the presense of a fixed assembler by using the command as -u < /dev/null If the command exits normally, the assembler fix already is installed. If the assembler complains that "-u" is an unknown flag, you need to order the fix. * On the IBM RS/6000, compiling code of the form extern int foo; ... foo ... static int foo; will cause the linker to report an undefined symbol `foo'. Although this behavior differs from most other systems, it is not a bug because redefining an `extern' variable as `static' is undefined in ANSI C. * AIX on the RS/6000 provides support (NLS) for environments outside of the United States. Compilers and assemblers use NLS to support locale-specific representations of various objects including floating-point numbers ("." vs "," for separating decimal fractions). There have been problems reported where the library linked with GCC does not produce the same floating-point formats that the assembler accepts. If you have this problem, set the LANG environment variable to "C" or "En_US". * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC version 1.3.0.1 or later fixes this problem. We do not yet have a PTF number for this fix. * There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that occurs when the `fldcr' instruction is used. GNU CC uses `fldcr' on the 88100 to serialize volatile memory references. Use the option `-mno-serialize-volatile' if your version of the assembler has this bug. * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning messages from the linker. These warning messages complain of mismatched psect attributes. You can ignore them. *Note VMS Install::. * On NewsOS version 3, if you include both of the files `stddef.h' and `sys/types.h', you get an error because there are two typedefs of `size_t'. You should change `sys/types.h' by adding these lines around the definition of `size_t': #ifndef _SIZE_T #define _SIZE_T ACTUAL TYPEDEF HERE #endif * On the Alliant, the system's own convention for returning structures and unions is unusual, and is not compatible with GNU CC no matter what options are used. * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different convention for structure and union returning. Use the option `-mhc-struct-return' to tell GNU CC to use a convention compatible with it. * On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved by function calls. However, the C compiler uses conventions compatible with BSD Unix: registers 2 through 5 may be clobbered by function calls. GNU CC uses the same convention as the Ultrix C compiler. You can use these options to produce code compatible with the Fortran compiler: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 * On the WE32k, you may find that programs compiled with GNU CC do not work with the standard shared C ilbrary. You may need to link with the ordinary C compiler. If you do so, you must specify the following options: -L/gnu/lib/gcc-lib/we32k-att-sysv/2.5 -lgcc -lc_s The first specifies where to find the library `libgcc.a' specified with the `-lgcc' option. GNU CC does linking by invoking `ld', just as `cc' does, and there is no reason why it *should* matter which compilation program you use to invoke `ld'. If someone tracks this problem down, it can probably be fixed easily. * On the Alpha, you may get assembler errors about invalid syntax as a result of floating point constants. This is due to a bug in the C library functions `ecvt', `fcvt' and `gcvt'. Given valid floating point numbers, they sometimes print `NaN'. * On Irix 4.0.5F (and perhaps in some other versions), an assembler bug sometimes reorders instructions incorrectly when optimization is turned on. If you think this may be happening to you, try using the GNU assembler; GAS version 2.1 supports ECOFF on Irix. Or use the `-noasmopt' option when you compile GNU CC with itself, and then again when you compile your program. (This is a temporary kludge to turn off assembler optimization on Irix.) If this proves to be what you need, edit the assembler spec in the file `specs' so that it unconditionally passes `-O0' to the assembler, and never passes `-O2' or `-O3'. File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble Problems Compiling Certain Programs =================================== * Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2 because of problems in DEC's versions of the X11 header files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding `-I/usr/include/mit' to use the MIT versions of the header files, using the `-traditional' switch to turn off ANSI C, or fixing the header files by adding this: #ifdef __STDC__ #define NeedFunctionPrototypes 0 #endif * If you have trouble compiling Perl on a SunOS 4 system, it may be because Perl specifies `-I/usr/ucbinclude'. This accesses the unfixed header files. Perl specifies the options -traditional -Dvolatile=__volatile__ -I/usr/include/sun -I/usr/ucbinclude -fpcc-struct-return all of which are unnecessary with GCC 2.4.5 and newer versions. You can make a properly working Perl by setting `ccflags' and `cppflags' to empty values in `config.sh', then typing `./doSH; make depend; make'. * On various 386 Unix systems derived from System V, including SCO, ISC, and ESIX, you may get error messages about running out of virtual memory while compiling certain programs. You can prevent this problem by linking GNU CC with the GNU malloc (which thus replaces the malloc that comes with the system). GNU malloc is available as a separate package, and also in the file `src/gmalloc.c' in the GNU Emacs 19 distribution. If you have installed GNU malloc as a separate library package, use this option when you relink GNU CC: MALLOC=/gnu/lib/libgmalloc.a Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy the object file to `gmalloc.o' and use this option when you relink GNU CC: MALLOC=gmalloc.o