--- gcc/gcc.info-11 2018/04/24 18:11:54 1.1.1.6 +++ gcc/gcc.info-11 2018/04/24 18:25:05 1.1.1.8 @@ -1,12 +1,13 @@ -This is Info file gcc.info, produced by Makeinfo-1.54 from the input +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 + Published by the Free Software Foundation 59 Temple Place - Suite 330 +Boston, MA 02111-1307 USA - Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc. + Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 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 @@ -14,1145 +15,1130 @@ 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. +that the sections entitled "GNU General Public License," "Funding for +Free Software," 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. +License," "Funding for Free Software," 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: Passes, Next: RTL, Prev: Interface, Up: Top +File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble -Passes and Files of the Compiler -******************************** +Installation Problems +===================== - The overall control structure of the compiler is in `toplev.c'. This -file is responsible for initialization, decoding arguments, opening and -closing files, and sequencing the passes. - - The parsing pass is invoked only once, to parse the entire input. -The RTL intermediate code for a function is generated as the function -is parsed, a statement at a time. Each statement is read in as a -syntax tree and then converted to RTL; then the storage for the tree -for the statement is reclaimed. Storage for types (and the expressions -for their sizes), declarations, and a representation of the binding -contours and how they nest, remain until the function is finished being -compiled; these are all needed to output the debugging information. - - Each time the parsing pass reads a complete function definition or -top-level declaration, it calls either the function -`rest_of_compilation', or the function `rest_of_decl_compilation' in -`toplev.c', which are responsible for all further processing necessary, -ending with output of the assembler language. All other compiler -passes run, in sequence, within `rest_of_compilation'. When that -function returns from compiling a function definition, the storage used -for that function definition's compilation is entirely freed, unless it -is an inline function (*note An Inline Function is As Fast As a Macro: -Inline.). - - Here is a list of all the passes of the compiler and their source -files. Also included is a description of where debugging dumps can be -requested with `-d' options. - - * Parsing. This pass reads the entire text of a function definition, - constructing partial syntax trees. This and RTL generation are no - longer truly separate passes (formerly they were), but it is - easier to think of them as separate. - - The tree representation does not entirely follow C syntax, because - it is intended to support other languages as well. - - Language-specific data type analysis is also done in this pass, - and every tree node that represents an expression has a data type - attached. Variables are represented as declaration nodes. - - Constant folding and some arithmetic simplifications are also done - during this pass. - - The language-independent source files for parsing are - `stor-layout.c', `fold-const.c', and `tree.c'. There are also - header files `tree.h' and `tree.def' which define the format of - the tree representation. - - The source files to parse C are `c-parse.in', `c-decl.c', - `c-typeck.c', `c-aux-info.c', `c-convert.c', and `c-lang.c' along - with header files `c-lex.h', and `c-tree.h'. - - The source files for parsing C++ are `cp-parse.y', `cp-class.c', - `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c', - `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c', - `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along - with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'. - - The special source files for parsing Objective C are - `objc-parse.y', `objc-actions.c', `objc-tree.def', and - `objc-actions.h'. Certain C-specific files are used for this as - well. - - The file `c-common.c' is also used for all of the above languages. - - * RTL generation. This is the conversion of syntax tree into RTL - code. It is actually done statement-by-statement during parsing, - but for most purposes it can be thought of as a separate pass. - - This is where the bulk of target-parameter-dependent code is found, - since often it is necessary for strategies to apply only when - certain standard kinds of instructions are available. The purpose - of named instruction patterns is to provide this information to - the RTL generation pass. - - Optimization is done in this pass for `if'-conditions that are - comparisons, boolean operations or conditional expressions. Tail - recursion is detected at this time also. Decisions are made about - how best to arrange loops and how to output `switch' statements. - - The source files for RTL generation include `stmt.c', `calls.c', - `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and - `emit-rtl.c'. Also, the file `insn-emit.c', generated from the - machine description by the program `genemit', is used in this - pass. The header file `expr.h' is used for communication within - this pass. - - The header files `insn-flags.h' and `insn-codes.h', generated from - the machine description by the programs `genflags' and `gencodes', - tell this pass which standard names are available for use and - which patterns correspond to them. - - Aside from debugging information output, none of the following - passes refers to the tree structure representation of the function - (only part of which is saved). - - The decision of whether the function can and should be expanded - inline in its subsequent callers is made at the end of rtl - generation. The function must meet certain criteria, currently - related to the size of the function and the types and number of - parameters it has. Note that this function may contain loops, - recursive calls to itself (tail-recursive functions can be - inlined!), gotos, in short, all constructs supported by GNU CC. - The file `integrate.c' contains the code to save a function's rtl - for later inlining and to inline that rtl when the function is - called. The header file `integrate.h' is also used for this - purpose. - - The option `-dr' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.rtl' to - the input file name. - - * Jump optimization. This pass simplifies jumps to the following - instruction, jumps across jumps, and jumps to jumps. It deletes - unreferenced labels and unreachable code, except that unreachable - code that contains a loop is not recognized as unreachable in this - pass. (Such loops are deleted later in the basic block analysis.) - It also converts some code originally written with jumps into - sequences of instructions that directly set values from the - results of comparisons, if the machine has such instructions. - - Jump optimization is performed two or three times. The first time - is immediately following RTL generation. The second time is after - CSE, but only if CSE says repeated jump optimization is needed. - The last time is right before the final pass. That time, - cross-jumping and deletion of no-op move instructions are done - together with the optimizations described above. - - The source file of this pass is `jump.c'. - - The option `-dj' causes a debugging dump of the RTL code after - this pass is run for the first time. This dump file's name is - made by appending `.jump' to the input file name. - - * Register scan. This pass finds the first and last use of each - register, as a guide for common subexpression elimination. Its - source is in `regclass.c'. - - * Jump threading. This pass detects a condition jump that branches - to an identical or inverse test. Such jumps can be `threaded' - through the second conditional test. The source code for this - pass is in `jump.c'. This optimization is only performed if - `-fthread-jumps' is enabled. - - * Common subexpression elimination. This pass also does constant - propagation. Its source file is `cse.c'. If constant propagation - causes conditional jumps to become unconditional or to become - no-ops, jump optimization is run again when CSE is finished. - - The option `-ds' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.cse' to - the input file name. - - * Loop optimization. This pass moves constant expressions out of - loops, and optionally does strength-reduction and loop unrolling - as well. Its source files are `loop.c' and `unroll.c', plus the - header `loop.h' used for communication between them. Loop - unrolling uses some functions in `integrate.c' and the header - `integrate.h'. - - The option `-dL' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.loop' to - the input file name. - - * If `-frerun-cse-after-loop' was enabled, a second common - subexpression elimination pass is performed after the loop - optimization pass. Jump threading is also done again at this time - if it was specified. - - The option `-dt' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.cse2' to - the input file name. - - * Stupid register allocation is performed at this point in a - nonoptimizing compilation. It does a little data flow analysis as - well. When stupid register allocation is in use, the next pass - executed is the reloading pass; the others in between are skipped. - The source file is `stupid.c'. - - * Data flow analysis (`flow.c'). This pass divides the program into - basic blocks (and in the process deletes unreachable loops); then - it computes which pseudo-registers are live at each point in the - program, and makes the first instruction that uses a value point at - the instruction that computed the value. - - This pass also deletes computations whose results are never used, - and combines memory references with add or subtract instructions - to make autoincrement or autodecrement addressing. - - The option `-df' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.flow' to - the input file name. If stupid register allocation is in use, this - dump file reflects the full results of such allocation. - - * Instruction combination (`combine.c'). This pass attempts to - combine groups of two or three instructions that are related by - data flow into single instructions. It combines the RTL - expressions for the instructions by substitution, simplifies the - result using algebra, and then attempts to match the result - against the machine description. - - The option `-dc' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.combine' - to the input file name. - - * Instruction scheduling (`sched.c'). This pass looks for - instructions whose output will not be available by the time that - it is used in subsequent instructions. (Memory loads and floating - point instructions often have this behavior on RISC machines). It - re-orders instructions within a basic block to try to separate the - definition and use of items that otherwise would cause pipeline - stalls. - - Instruction scheduling is performed twice. The first time is - immediately after instruction combination and the second is - immediately after reload. - - The option `-dS' causes a debugging dump of the RTL code after this - pass is run for the first time. The dump file's name is made by - appending `.sched' to the input file name. - - * Register class preferencing. The RTL code is scanned to find out - which register class is best for each pseudo register. The source - file is `regclass.c'. - - * Local register allocation (`local-alloc.c'). This pass allocates - hard registers to pseudo registers that are used only within one - basic block. Because the basic block is linear, it can use fast - and powerful techniques to do a very good job. - - The option `-dl' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.lreg' to - the input file name. - - * Global register allocation (`global.c'). This pass allocates hard - registers for the remaining pseudo registers (those whose life - spans are not contained in one basic block). - - * Reloading. This pass renumbers pseudo registers with the hardware - registers numbers they were allocated. Pseudo registers that did - not get hard registers are replaced with stack slots. Then it - finds instructions that are invalid because a value has failed to - end up in a register, or has ended up in a register of the wrong - kind. It fixes up these instructions by reloading the - problematical values temporarily into registers. Additional - instructions are generated to do the copying. - - The reload pass also optionally eliminates the frame pointer and - inserts instructions to save and restore call-clobbered registers - around calls. - - Source files are `reload.c' and `reload1.c', plus the header - `reload.h' used for communication between them. - - The option `-dg' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.greg' to - the input file name. - - * Instruction scheduling is repeated here to try to avoid pipeline - stalls due to memory loads generated for spilled pseudo registers. - - The option `-dR' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.sched2' - to the input file name. - - * Jump optimization is repeated, this time including cross-jumping - and deletion of no-op move instructions. - - The option `-dJ' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.jump2' to - the input file name. - - * Delayed branch scheduling. This optional pass attempts to find - instructions that can go into the delay slots of other - instructions, usually jumps and calls. The source file name is - `reorg.c'. - - The option `-dd' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.dbr' to - the input file name. - - * Conversion from usage of some hard registers to usage of a register - stack may be done at this point. Currently, this is supported only - for the floating-point registers of the Intel 80387 coprocessor. - The source file name is `reg-stack.c'. - - The options `-dk' causes a debugging dump of the RTL code after - this pass. This dump file's name is made by appending `.stack' to - the input file name. - - * Final. This pass outputs the assembler code for the function. It - is also responsible for identifying spurious test and compare - instructions. Machine-specific peephole optimizations are - performed at the same time. The function entry and exit sequences - are generated directly as assembler code in this pass; they never - exist as RTL. - - The source files are `final.c' plus `insn-output.c'; the latter is - generated automatically from the machine description by the tool - `genoutput'. The header file `conditions.h' is used for - communication between these files. - - * Debugging information output. This is run after final because it - must output the stack slot offsets for pseudo registers that did - not get hard registers. Source files are `dbxout.c' for DBX - symbol table format, `sdbout.c' for SDB symbol table format, and - `dwarfout.c' for DWARF symbol table format. + This is a list of problems (and some apparent problems which don't +really mean anything is wrong) that show up during installation of GNU +CC. - Some additional files are used by all or many passes: + * On certain systems, defining certain environment variables such as + `CC' can interfere with the functioning of `make'. - * Every pass uses `machmode.def' and `machmode.h' which define the - machine modes. + * If you encounter seemingly strange errors when trying to build the + compiler in a directory other than the source directory, it could + be because you have previously configured the compiler in the + source directory. Make sure you have done all the necessary + preparations. *Note Other Dir::. - * Several passes use `real.h', which defines the default - representation of floating point constants and how to operate on - them. + * If you build GNU CC on a BSD system using a directory stored in a + System V file system, problems may occur in running `fixincludes' + if the System V file system doesn't support symbolic links. These + problems result in a failure to fix the declaration of `size_t' in + `sys/types.h'. If you find that `size_t' is a signed type and + that type mismatches occur, this could be the cause. + + The solution is not to use such a directory for building GNU CC. + + * In previous versions of GNU CC, the `gcc' driver program looked for + `as' and `ld' in various places; for example, in files beginning + with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in + the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'. + + Thus, to use a version of `as' or `ld' that is not the system + default, for example `gas' or GNU `ld', you must put them in that + directory (or make links to them from that directory). + + * Some commands executed when making the compiler may fail (return a + non-zero status) and be ignored by `make'. These failures, which + are often due to files that were not found, are expected, and can + safely be ignored. + + * It is normal to have warnings in compiling certain files about + unreachable code and about enumeration type clashes. These files' + names begin with `insn-'. Also, `real.c' may get some warnings + that you can ignore. + + * Sometimes `make' recompiles parts of the compiler when installing + the compiler. In one case, this was traced down to a bug in + `make'. Either ignore the problem or switch to GNU Make. + + * If you have installed a program known as purify, you may find that + it causes errors while linking `enquire', which is part of building + GNU CC. The fix is to get rid of the file `real-ld' which purify + installs--so that GNU CC won't try to use it. + + * On Linux SLS 1.01, there is a problem with `libc.a': it does not + contain the obstack functions. However, GNU CC assumes that the + obstack functions are in `libc.a' when it is the GNU C library. + To work around this problem, change the `__GNU_LIBRARY__' + conditional around line 31 to `#if 1'. + + * On some 386 systems, building the compiler never finishes because + `enquire' hangs due to a hardware problem in the motherboard--it + reports floating point exceptions to the kernel incorrectly. You + can install GNU CC except for `float.h' by patching out the + command to run `enquire'. You may also be able to fix the problem + for real by getting a replacement motherboard. This problem was + observed in Revision E of the Micronics motherboard, and is fixed + in Revision F. It has also been observed in the MYLEX MXA-33 + motherboard. + + If you encounter this problem, you may also want to consider + removing the FPU from the socket during the compilation. + Alternatively, if you are running SCO Unix, you can reboot and + force the FPU to be ignored. To do this, type `hd(40)unix auto + ignorefpu'. + + * On some 386 systems, GNU CC crashes trying to compile `enquire.c'. + This happens on machines that don't have a 387 FPU chip. On 386 + machines, the system kernel is supposed to emulate the 387 when you + don't have one. The crash is due to a bug in the emulator. + + One of these systems is the Unix from Interactive Systems: 386/ix. + On this system, an alternate emulator is provided, and it does + work. To use it, execute this command as super-user: + + ln /etc/emulator.rel1 /etc/emulator + + and then reboot the system. (The default emulator file remains + present under the name `emulator.dflt'.) + + Try using `/etc/emulator.att', if you have such a problem on the + SCO system. + + Another system which has this problem is Esix. We don't know + whether it has an alternate emulator that works. + + On NetBSD 0.8, a similar problem manifests itself as these error + messages: + + enquire.c: In function `fprop': + enquire.c:2328: floating overflow + + * On SCO systems, when compiling GNU CC with the system's compiler, + do not use `-O'. Some versions of the system's compiler miscompile + GNU CC with `-O'. + + * Sometimes on a Sun 4 you may observe a crash in the program + `genflags' or `genoutput' while building GNU CC. This is said to + be due to a bug in `sh'. You can probably get around it by running + `genflags' or `genoutput' manually and then retrying the `make'. + + * On Solaris 2, executables of GNU CC version 2.0.2 are commonly + available, but they have a bug that shows up when compiling current + versions of GNU CC: undefined symbol errors occur during assembly + if you use `-g'. + + The solution is to compile the current version of GNU CC without + `-g'. That makes a working compiler which you can use to recompile + with `-g'. + + * Solaris 2 comes with a number of optional OS packages. Some of + these packages are needed to use GNU CC fully. If you did not + install all optional packages when installing Solaris, you will + need to verify that the packages that GNU CC needs are installed. + + To check whether an optional package is installed, use the + `pkginfo' command. To add an optional package, use the `pkgadd' + command. For further details, see the Solaris documentation. + + For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc', + `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'. + + For Solaris 2.2, GNU CC needs an additional seventh package: + `SUNWsprot'. + + * On Solaris 2, trying to use the linker and other tools in + `/usr/ucb' to install GNU CC has been observed to cause trouble. + For example, the linker may hang indefinitely. The fix is to + remove `/usr/ucb' from your `PATH'. + + * If you use the 1.31 version of the MIPS assembler (such as was + shipped with Ultrix 3.1), you will need to use the + -fno-delayed-branch switch when optimizing floating point code. + Otherwise, the assembler will complain when the GCC compiler fills + a branch delay slot with a floating point instruction, such as + `add.d'. + + * If on a MIPS system you get an error message saying "does not have + gp sections for all it's [sic] sectons [sic]", don't worry about + it. This happens whenever you use GAS with the MIPS linker, but + there is not really anything wrong, and it is okay to use the + output file. You can stop such warnings by installing the GNU + linker. + + It would be nice to extend GAS to produce the gp tables, but they + are optional, and there should not be a warning about their + absence. + + * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU + CC at all unless it has been fixed with `fixincludes'. This causes + problems in building GNU CC. Once GNU CC is installed, the + problems go away. + + To work around this problem, when making the stage 1 compiler, + specify this option to Make: + + GCC_FOR_TARGET="./xgcc -B./ -I./include" + + When making stage 2 and stage 3, specify this option: + + CFLAGS="-g -I./include" + + * Users have reported some problems with version 2.0 of the MIPS + compiler tools that were shipped with Ultrix 4.1. Version 2.10 + which came with Ultrix 4.2 seems to work fine. + + Users have also reported some problems with version 2.20 of the + MIPS compiler tools that were shipped with RISC/os 4.x. The + earlier version 2.11 seems to work fine. + + * Some versions of the MIPS linker will issue an assertion failure + when linking code that uses `alloca' against shared libraries on + RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the + linker, that is supposed to be fixed in future revisions. To + protect against this, GNU CC passes `-non_shared' to the linker + unless you pass an explicit `-shared' or `-call_shared' switch. + + * On System V release 3, you may get this error message while + linking: + + ld fatal: failed to write symbol name SOMETHING + in strings table for file WHATEVER + + This probably indicates that the disk is full or your ULIMIT won't + allow the file to be as large as it needs to be. + + This problem can also result because the kernel parameter `MAXUMEM' + is too small. If so, you must regenerate the kernel and make the + value much larger. The default value is reported to be 1024; a + value of 32768 is said to work. Smaller values may also work. + + * On System V, if you get an error like this, + + /usr/local/lib/bison.simple: In function `yyparse': + /usr/local/lib/bison.simple:625: virtual memory exhausted + + that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'. + + * Current GNU CC versions probably do not work on version 2 of the + NeXT operating system. + + * On NeXTStep 3.0, the Objective C compiler does not work, due, + apparently, to a kernel bug that it happens to trigger. This + problem does not happen on 3.1. + + * On the Tower models 4N0 and 6N0, by default a process is not + allowed to have more than one megabyte of memory. GNU CC cannot + compile itself (or many other programs) with `-O' in that much + memory. + + To solve this problem, reconfigure the kernel adding the following + line to the configuration file: + + MAXUMEM = 4096 + + * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a + bug in the assembler that must be fixed before GNU CC can be + built. This bug manifests itself during the first stage of + compilation, while building `libgcc2.a': - * All the passes that work with RTL use the header files `rtl.h' and - `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also - use these files to read and work with the machine description RTL. - - * Several passes refer to the header file `insn-config.h' which - contains a few parameters (C macro definitions) generated - automatically from the machine description RTL by the tool - `genconfig'. - - * Several passes use the instruction recognizer, which consists of - `recog.c' and `recog.h', plus the files `insn-recog.c' and - `insn-extract.c' that are generated automatically from the machine - description by the tools `genrecog' and `genextract'. - - * Several passes use the header files `regs.h' which defines the - information recorded about pseudo register usage, and - `basic-block.h' which defines the information recorded about basic - blocks. - - * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector - with a bit for each hard register, and some macros to manipulate - it. This type is just `int' if the machine has few enough hard - registers; otherwise it is an array of `int' and some of the - macros expand into loops. - - * Several passes use instruction attributes. A definition of the - attributes defined for a particular machine is in file - `insn-attr.h', which is generated from the machine description by - the program `genattr'. The file `insn-attrtab.c' contains - subroutines to obtain the attribute values for insns. It is - generated from the machine description by the program `genattrtab'. + _floatdisf + cc1: warning: `-g' option not supported on this version of GCC + cc1: warning: `-g1' option not supported on this version of GCC + ./xgcc: Internal compiler error: program as got fatal signal 11 + + A patched version of the assembler is available by anonymous ftp + from `altdorf.ai.mit.edu' as the file + `archive/cph/hpux-8.0-assembler'. If you have HP software support, + the patch can also be obtained directly from HP, as described in + the following note: + + This is the patched assembler, to patch SR#1653-010439, where + the assembler aborts on floating point constants. + + The bug is not really in the assembler, but in the shared + library version of the function "cvtnum(3c)". The bug on + "cvtnum(3c)" is SR#4701-078451. Anyway, the attached + assembler uses the archive library version of "cvtnum(3c)" + and thus does not exhibit the bug. + + This patch is also known as PHCO_4484. + + * On HP-UX version 8.05, but not on 8.07 or more recent versions, + the `fixproto' shell script triggers a bug in the system shell. + If you encounter this problem, upgrade your operating system or + use BASH (the GNU shell) to run `fixproto'. + + * Some versions of the Pyramid C compiler are reported to be unable + to compile GNU CC. You must use an older version of GNU CC for + bootstrapping. One indication of this problem is if you get a + crash when GNU CC compiles the function `muldi3' in file + `libgcc2.c'. + + You may be able to succeed by getting GNU CC version 1, installing + it, and using it to compile GNU CC version 2. The bug in the + Pyramid C compiler does not seem to affect GNU CC version 1. + + * There may be similar problems on System V Release 3.1 on 386 + systems. + + * On the Intel Paragon (an i860 machine), if you are using operating + system version 1.0, you will get warnings or errors about + redefinition of `va_arg' when you build GNU CC. + + If this happens, then you need to link most programs with the + library `iclib.a'. You must also modify `stdio.h' as follows: + before the lines + + #if defined(__i860__) && !defined(_VA_LIST) + #include + + 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 + Configurations::. + + * A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto + program to report an error of the form: + + ./fixproto: sh internal 1K buffer overflow + + To fix this, change the first line of the fixproto script to look + like: + + #!/bin/ksh  -File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top +File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble -RTL Representation -****************** +Cross-Compiler Problems +======================= - Most of the work of the compiler is done on an intermediate -representation called register transfer language. In this language, -the instructions to be output are described, pretty much one by one, in -an algebraic form that describes what the instruction does. - - RTL is inspired by Lisp lists. It has both an internal form, made -up of structures that point at other structures, and a textual form -that is used in the machine description and in printed debugging dumps. -The textual form uses nested parentheses to indicate the pointers in -the internal form. + You may run into problems with cross compilation on certain machines, +for several reasons. -* Menu: + * 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. -* RTL Objects:: Expressions vs vectors vs strings vs integers. -* Accessors:: Macros to access expression operands or vector elts. -* Flags:: Other flags in an RTL expression. -* Machine Modes:: Describing the size and format of a datum. -* Constants:: Expressions with constant values. -* Regs and Memory:: Expressions representing register contents or memory. -* Arithmetic:: Expressions representing arithmetic on other expressions. -* Comparisons:: Expressions representing comparison of expressions. -* Bit Fields:: Expressions representing bitfields in memory or reg. -* Conversions:: Extending, truncating, floating or fixing. -* RTL Declarations:: Declaring volatility, constancy, etc. -* Side Effects:: Expressions for storing in registers, etc. -* Incdec:: Embedded side-effects for autoincrement addressing. -* Assembler:: Representing `asm' with operands. -* Insns:: Expression types for entire insns. -* Calls:: RTL representation of function call insns. -* Sharing:: Some expressions are unique; others *must* be copied. -* Reading RTL:: Reading textual RTL from a file. + +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. + + * 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/usr/local/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/usr/local/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. + + * 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 emulator uses an obsolete and + incompatible format. Long doubles do not work in Sun OS version + 4.1.1 due to a problem in a Sun library. Long doubles do work on + Sun OS versions 4.1.2 and higher, but GNU CC does not enable them + by default. Long doubles appear to work in Sun OS 5.x (Solaris + 2.x). + + * 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. + + * In extremely rare cases involving some very large functions you may + receive errors from the HP linker complaining about an out of + bounds unconditional branch offset. This used to occur more often + in previous versions of GNU CC, but is now exceptionally rare. If + you should run into it, you can work around by making your + function smaller. + + * 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". + + * Even if you specify `-fdollars-in-identifiers', you cannot + successfully use `$' in identifiers on the RS/6000 due to a + restriction in the IBM assembler. GAS supports these identifiers. + + * 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. You can obtain + XLC-1.3.0.2 by requesting PTF 421749 from IBM. + + * 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 library. You may need to link + with the ordinary C compiler. If you do so, you must specify the + following options: + + -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.7.1 -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: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL +File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble + +Problems Compiling Certain Programs +=================================== + + Certain programs have problems compiling. + + * 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 -RTL Object Types -================ + -traditional -Dvolatile=__volatile__ + -I/usr/include/sun -I/usr/ucbinclude + -fpcc-struct-return - RTL uses five kinds of objects: expressions, integers, wide integers, -strings and vectors. Expressions are the most important ones. An RTL -expression ("RTX", for short) is a C structure, but it is usually -referred to with a pointer; a type that is given the typedef name `rtx'. - - An integer is simply an `int'; their written form uses decimal -digits. A wide integer is an integral object whose type is -`HOST_WIDE_INT' (*note Config::.); their written form uses decimal -digits. - - A string is a sequence of characters. In core it is represented as a -`char *' in usual C fashion, and it is written in C syntax as well. -However, strings in RTL may never be null. If you write an empty -string in a machine description, it is represented in core as a null -pointer rather than as a pointer to a null character. In certain -contexts, these null pointers instead of strings are valid. Within RTL -code, strings are most commonly found inside `symbol_ref' expressions, -but they appear in other contexts in the RTL expressions that make up -machine descriptions. - - A vector contains an arbitrary number of pointers to expressions. -The number of elements in the vector is explicitly present in the -vector. The written form of a vector consists of square brackets -(`[...]') surrounding the elements, in sequence and with whitespace -separating them. Vectors of length zero are not created; null pointers -are used instead. - - Expressions are classified by "expression codes" (also called RTX -codes). The expression code is a name defined in `rtl.def', which is -also (in upper case) a C enumeration constant. The possible expression -codes and their meanings are machine-independent. The code of an RTX -can be extracted with the macro `GET_CODE (X)' and altered with -`PUT_CODE (X, NEWCODE)'. - - The expression code determines how many operands the expression -contains, and what kinds of objects they are. In RTL, unlike Lisp, you -cannot tell by looking at an operand what kind of object it is. -Instead, you must know from its context--from the expression code of -the containing expression. For example, in an expression of code -`subreg', the first operand is to be regarded as an expression and the -second operand as an integer. In an expression of code `plus', there -are two operands, both of which are to be regarded as expressions. In -a `symbol_ref' expression, there is one operand, which is to be -regarded as a string. - - Expressions are written as parentheses containing the name of the -expression type, its flags and machine mode if any, and then the -operands of the expression (separated by spaces). - - Expression code names in the `md' file are written in lower case, -but when they appear in C code they are written in upper case. In this -manual, they are shown as follows: `const_int'. + most of which are unnecessary with GCC 2.4.5 and newer versions. + You can make a properly working Perl by setting `ccflags' to + `-fwritable-strings' (implied by the `-traditional' in the + original options) and `cppflags' to empty in `config.sh', then + typing `./doSH; make depend; make'. - In a few contexts a null pointer is valid where an expression is -normally wanted. The written form of this is `(nil)'. + * 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=/usr/local/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  -File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL +File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble + +Incompatibilities of GNU CC +=========================== -Access to Operands + There are several noteworthy incompatibilities between GNU C and most +existing (non-ANSI) versions of C. The `-traditional' option +eliminates many of these incompatibilities, *but not all*, by telling +GNU C to behave like the other C compilers. + + * GNU CC normally makes string constants read-only. If several + identical-looking string constants are used, GNU CC stores only one + copy of the string. + + One consequence is that you cannot call `mktemp' with a string + constant argument. The function `mktemp' always alters the string + its argument points to. + + Another consequence is that `sscanf' does not work on some systems + when passed a string constant as its format control string or + input. This is because `sscanf' incorrectly tries to write into + the string constant. Likewise `fscanf' and `scanf'. + + The best solution to these problems is to change the program to use + `char'-array variables with initialization strings for these + purposes instead of string constants. But if this is not possible, + you can use the `-fwritable-strings' flag, which directs GNU CC to + handle string constants the same way most C compilers do. + `-traditional' also has this effect, among others. + + * `-2147483648' is positive. + + This is because 2147483648 cannot fit in the type `int', so + (following the ANSI C rules) its data type is `unsigned long int'. + Negating this value yields 2147483648 again. + + * GNU CC does not substitute macro arguments when they appear inside + of string constants. For example, the following macro in GNU CC + + #define foo(a) "a" + + will produce output `"a"' regardless of what the argument A is. + + The `-traditional' option directs GNU CC to handle such cases + (among others) in the old-fashioned (non-ANSI) fashion. + + * When you use `setjmp' and `longjmp', the only automatic variables + guaranteed to remain valid are those declared `volatile'. This is + a consequence of automatic register allocation. Consider this + function: + + jmp_buf j; + + foo () + { + int a, b; + + a = fun1 (); + if (setjmp (j)) + return a; + + a = fun2 (); + /* `longjmp (j)' may occur in `fun3'. */ + return a + fun3 (); + } + + Here `a' may or may not be restored to its first value when the + `longjmp' occurs. If `a' is allocated in a register, then its + first value is restored; otherwise, it keeps the last value stored + in it. + + If you use the `-W' option with the `-O' option, you will get a + warning when GNU CC thinks such a problem might be possible. + + The `-traditional' option directs GNU C to put variables in the + stack by default, rather than in registers, in functions that call + `setjmp'. This results in the behavior found in traditional C + compilers. + + * Programs that use preprocessing directives in the middle of macro + arguments do not work with GNU CC. For example, a program like + this will not work: + + foobar ( + #define luser + hack) + + ANSI C does not permit such a construct. It would make sense to + support it when `-traditional' is used, but it is too much work to + implement. + + * Declarations of external variables and functions within a block + apply only to the block containing the declaration. In other + words, they have the same scope as any other declaration in the + same place. + + In some other C compilers, a `extern' declaration affects all the + rest of the file even if it happens within a block. + + The `-traditional' option directs GNU C to treat all `extern' + declarations as global, like traditional compilers. + + * In traditional C, you can combine `long', etc., with a typedef + name, as shown here: + + typedef int foo; + typedef long foo bar; + + In ANSI C, this is not allowed: `long' and other type modifiers + require an explicit `int'. Because this criterion is expressed by + Bison grammar rules rather than C code, the `-traditional' flag + cannot alter it. + + * PCC allows typedef names to be used as function parameters. The + difficulty described immediately above applies here too. + + * PCC allows whitespace in the middle of compound assignment + operators such as `+='. GNU CC, following the ANSI standard, does + not allow this. The difficulty described immediately above + applies here too. + + * GNU CC complains about unterminated character constants inside of + preprocessing conditionals that fail. Some programs have English + comments enclosed in conditionals that are guaranteed to fail; if + these comments contain apostrophes, GNU CC will probably report an + error. For example, this code would produce an error: + + #if 0 + You can't expect this to work. + #endif + + The best solution to such a problem is to put the text into an + actual C comment delimited by `/*...*/'. However, `-traditional' + suppresses these error messages. + + * Many user programs contain the declaration `long time ();'. In the + past, the system header files on many systems did not actually + declare `time', so it did not matter what type your program + declared it to return. But in systems with ANSI C headers, `time' + is declared to return `time_t', and if that is not the same as + `long', then `long time ();' is erroneous. + + The solution is to change your program to use `time_t' as the + return type of `time'. + + * When compiling functions that return `float', PCC converts it to a + double. GNU CC actually returns a `float'. If you are concerned + with PCC compatibility, you should declare your functions to return + `double'; you might as well say what you mean. + + * When compiling functions that return structures or unions, GNU CC + output code normally uses a method different from that used on most + versions of Unix. As a result, code compiled with GNU CC cannot + call a structure-returning function compiled with PCC, and vice + versa. + + The method used by GNU CC is as follows: a structure or union + which is 1, 2, 4 or 8 bytes long is returned like a scalar. A + structure or union with any other size is stored into an address + supplied by the caller (usually in a special, fixed register, but + on some machines it is passed on the stack). The + machine-description macros `STRUCT_VALUE' and + `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. + + By contrast, PCC on most target machines returns structures and + unions of any size by copying the data into an area of static + storage, and then returning the address of that storage as if it + were a pointer value. The caller must copy the data from that + memory area to the place where the value is wanted. GNU CC does + not use this method because it is slower and nonreentrant. + + On some newer machines, PCC uses a reentrant convention for all + structure and union returning. GNU CC on most of these machines + uses a compatible convention when returning structures and unions + in memory, but still returns small structures and unions in + registers. + + You can tell GNU CC to use a compatible convention for all + structure and union returning with the option + `-fpcc-struct-return'. + + * GNU C complains about program fragments such as `0x74ae-0x4000' + which appear to be two hexadecimal constants separated by the minus + operator. Actually, this string is a single "preprocessing token". + Each such token must correspond to one token in C. Since this + does not, GNU C prints an error message. Although it may appear + obvious that what is meant is an operator and two values, the ANSI + C standard specifically requires that this be treated as erroneous. + + A "preprocessing token" is a "preprocessing number" if it begins + with a digit and is followed by letters, underscores, digits, + periods and `e+', `e-', `E+', or `E-' character sequences. + + To make the above program fragment valid, place whitespace in + front of the minus sign. This whitespace will end the + preprocessing number. + + +File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble + +Fixed Header Files ================== - For each expression type `rtl.def' specifies the number of contained -objects and their kinds, with four possibilities: `e' for expression -(actually a pointer to an expression), `i' for integer, `w' for wide -integer, `s' for string, and `E' for vector of expressions. The -sequence of letters for an expression code is called its "format". -Thus, the format of `subreg' is `ei'. - - A few other format characters are used occasionally: - -`u' - `u' is equivalent to `e' except that it is printed differently in - debugging dumps. It is used for pointers to insns. - -`n' - `n' is equivalent to `i' except that it is printed differently in - debugging dumps. It is used for the line number or code number of - a `note' insn. - -`S' - `S' indicates a string which is optional. In the RTL objects in - core, `S' is equivalent to `s', but when the object is read, from - an `md' file, the string value of this operand may be omitted. An - omitted string is taken to be the null string. - -`V' - `V' indicates a vector which is optional. In the RTL objects in - core, `V' is equivalent to `E', but when the object is read from - an `md' file, the vector value of this operand may be omitted. An - omitted vector is effectively the same as a vector of no elements. - -`0' - `0' means a slot whose contents do not fit any normal category. - `0' slots are not printed at all in dumps, and are often used in - special ways by small parts of the compiler. - - There are macros to get the number of operands, the format, and the -class of an expression code: - -`GET_RTX_LENGTH (CODE)' - Number of operands of an RTX of code CODE. - -`GET_RTX_FORMAT (CODE)' - The format of an RTX of code CODE, as a C string. - -`GET_RTX_CLASS (CODE)' - A single character representing the type of RTX operation that code - CODE performs. - - The following classes are defined: - - `o' - An RTX code that represents an actual object, such as `reg' or - `mem'. `subreg' is not in this class. - - `<' - An RTX code for a comparison. The codes in this class are - `NE', `EQ', `LE', `LT', `GE', `GT', `LEU', `LTU', `GEU', - `GTU'. - - `1' - An RTX code for a unary arithmetic operation, such as `neg'. - - `c' - An RTX code for a commutative binary operation, other than - `NE' and `EQ' (which have class `<'). - - `2' - An RTX code for a noncommutative binary operation, such as - `MINUS'. - - `b' - An RTX code for a bitfield operation, either `ZERO_EXTRACT' or - `SIGN_EXTRACT'. - - `3' - An RTX code for other three input operations, such as - `IF_THEN_ELSE'. - - `i' - An RTX code for a machine insn (`INSN', `JUMP_INSN', and - `CALL_INSN'). - - `m' - An RTX code for something that matches in insns, such as - `MATCH_DUP'. - - `x' - All other RTX codes. - - Operands of expressions are accessed using the macros `XEXP', -`XINT', `XWINT' and `XSTR'. Each of these macros takes two arguments: -an expression-pointer (RTX) and an operand number (counting from zero). -Thus, - - XEXP (X, 2) - -accesses operand 2 of expression X, as an expression. - - XINT (X, 2) - -accesses the same operand as an integer. `XSTR', used in the same -fashion, would access it as a string. - - Any operand can be accessed as an integer, as an expression or as a -string. You must choose the correct method of access for the kind of -value actually stored in the operand. You would do this based on the -expression code of the containing expression. That is also how you -would know how many operands there are. - - For example, if X is a `subreg' expression, you know that it has two -operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, -1)'. If you did `XINT (X, 0)', you would get the address of the -expression operand but cast as an integer; that might occasionally be -useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP -(X, 1)' would also compile without error, and would return the second, -integer operand cast as an expression pointer, which would probably -result in a crash when accessed. Nothing stops you from writing `XEXP -(X, 28)' either, but this will access memory past the end of the -expression with unpredictable results. - - Access to operands which are vectors is more complicated. You can -use the macro `XVEC' to get the vector-pointer itself, or the macros -`XVECEXP' and `XVECLEN' to access the elements and length of a vector. - -`XVEC (EXP, IDX)' - Access the vector-pointer which is operand number IDX in EXP. - -`XVECLEN (EXP, IDX)' - Access the length (number of elements) in the vector which is in - operand number IDX in EXP. This value is an `int'. - -`XVECEXP (EXP, IDX, ELTNUM)' - Access element number ELTNUM in the vector which is in operand - number IDX in EXP. This value is an RTX. - - It is up to you to make sure that ELTNUM is not negative and is - less than `XVECLEN (EXP, IDX)'. - - All the macros defined in this section expand into lvalues and -therefore can be used to assign the operands, lengths and vector -elements as well as to access them. + GNU CC needs to install corrected versions of some system header +files. This is because most target systems have some header files that +won't work with GNU CC unless they are changed. Some have bugs, some +are incompatible with ANSI C, and some depend on special features of +other compilers. + + Installing GNU CC automatically creates and installs the fixed header +files, by running a program called `fixincludes' (or for certain +targets an alternative such as `fixinc.svr4'). Normally, you don't +need to pay attention to this. But there are cases where it doesn't do +the right thing automatically. + + * If you update the system's header files, such as by installing a + new system version, the fixed header files of GNU CC are not + automatically updated. The easiest way to update them is to + reinstall GNU CC. (If you want to be clever, look in the makefile + and you can find a shortcut.) + + * On some systems, in particular SunOS 4, header file directories + contain machine-specific symbolic links in certain places. This + makes it possible to share most of the header files among hosts + running the same version of SunOS 4 on different machine models. + + The programs that fix the header files do not understand this + special way of using symbolic links; therefore, the directory of + fixed header files is good only for the machine model used to + build it. + + In SunOS 4, only programs that look inside the kernel will notice + the difference between machine models. Therefore, for most + purposes, you need not be concerned about this. + + It is possible to make separate sets of fixed header files for the + different machine models, and arrange a structure of symbolic + links so as to use the proper set, but you'll have to do this by + hand. + + * On Lynxos, GNU CC by default does not fix the header files. This + is because bugs in the shell cause the `fixincludes' script to + fail. + + This means you will encounter problems due to bugs in the system + header files. It may be no comfort that they aren't GNU CC's + fault, but it does mean that there's nothing for us to do about + them.  -File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL +File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble -Flags in an RTL Expression -========================== +Standard Libraries +================== - RTL expressions contain several flags (one-bit bitfields) that are -used in certain types of expression. Most often they are accessed with -the following macros: - -`MEM_VOLATILE_P (X)' - In `mem' expressions, nonzero for volatile memory references. - Stored in the `volatil' field and printed as `/v'. - -`MEM_IN_STRUCT_P (X)' - In `mem' expressions, nonzero for reference to an entire - structure, union or array, or to a component of one. Zero for - references to a scalar variable or through a pointer to a scalar. - Stored in the `in_struct' field and printed as `/s'. - -`REG_LOOP_TEST_P' - In `reg' expressions, nonzero if this register's entire life is - contained in the exit test code for some loop. Stored in the - `in_struct' field and printed as `/s'. - -`REG_USERVAR_P (X)' - In a `reg', nonzero if it corresponds to a variable present in the - user's source code. Zero for temporaries generated internally by - the compiler. Stored in the `volatil' field and printed as `/v'. - -`REG_FUNCTION_VALUE_P (X)' - Nonzero in a `reg' if it is the place in which this function's - value is going to be returned. (This happens only in a hard - register.) Stored in the `integrated' field and printed as `/i'. - - The same hard register may be used also for collecting the values - of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero - in this kind of use. - -`SUBREG_PROMOTED_VAR_P' - Nonzero in a `subreg' if it was made when accessing an object that - was promoted to a wider mode in accord with the `PROMOTED_MODE' - machine description macro (*note Storage Layout::.). In this - case, the mode of the `subreg' is the declared mode of the object - and the mode of `SUBREG_REG' is the mode of the register that - holds the object. Promoted variables are always either sign- or - zero-extended to the wider mode on every assignment. Stored in - the `in_struct' field and printed as `/s'. - -`SUBREG_PROMOTED_UNSIGNED_P' - Nonzero in a `subreg' that has `SUBREG_PROMOTED_VAR_P' nonzero if - the object being referenced is kept zero-extended and zero if it - is kept sign-extended. Stored in the `unchanging' field and - printed as `/u'. - -`RTX_UNCHANGING_P (X)' - Nonzero in a `reg' or `mem' if the value is not changed. (This - flag is not set for memory references via pointers to constants. - Such pointers only guarantee that the object will not be changed - explicitly by the current function. The object might be changed by - other functions or by aliasing.) Stored in the `unchanging' field - and printed as `/u'. - -`RTX_INTEGRATED_P (INSN)' - Nonzero in an insn if it resulted from an in-line function call. - Stored in the `integrated' field and printed as `/i'. This may be - deleted; nothing currently depends on it. - -`SYMBOL_REF_USED (X)' - In a `symbol_ref', indicates that X has been used. This is - normally only used to ensure that X is only declared external - once. Stored in the `used' field. - -`SYMBOL_REF_FLAG (X)' - In a `symbol_ref', this is used as a flag for machine-specific - purposes. Stored in the `volatil' field and printed as `/v'. - -`LABEL_OUTSIDE_LOOP_P' - In `label_ref' expressions, nonzero if this is a reference to a - label that is outside the innermost loop containing the reference - to the label. Stored in the `in_struct' field and printed as `/s'. - -`INSN_DELETED_P (INSN)' - In an insn, nonzero if the insn has been deleted. Stored in the - `volatil' field and printed as `/v'. - -`INSN_ANNULLED_BRANCH_P (INSN)' - In an `insn' in the delay slot of a branch insn, indicates that an - annulling branch should be used. See the discussion under - `sequence' below. Stored in the `unchanging' field and printed as - `/u'. - -`INSN_FROM_TARGET_P (INSN)' - In an `insn' in a delay slot of a branch, indicates that the insn - is from the target of the branch. If the branch insn has - `INSN_ANNULLED_BRANCH_P' set, this insn should only be executed if - the branch is taken. For annulled branches with this bit clear, - the insn should be executed only if the branch is not taken. - Stored in the `in_struct' field and printed as `/s'. - -`CONSTANT_POOL_ADDRESS_P (X)' - Nonzero in a `symbol_ref' if it refers to part of the current - function's "constants pool". These are addresses close to the - beginning of the function, and GNU CC assumes they can be addressed - directly (perhaps with the help of base registers). Stored in the - `unchanging' field and printed as `/u'. - -`CONST_CALL_P (X)' - In a `call_insn', indicates that the insn represents a call to a - const function. Stored in the `unchanging' field and printed as - `/u'. - -`LABEL_PRESERVE_P (X)' - In a `code_label', indicates that the label can never be deleted. - Labels referenced by a non-local goto will have this bit set. - Stored in the `in_struct' field and printed as `/s'. - -`SCHED_GROUP_P (INSN)' - During instruction scheduling, in an insn, indicates that the - previous insn must be scheduled together with this insn. This is - used to ensure that certain groups of instructions will not be - split up by the instruction scheduling pass, for example, `use' - insns before a `call_insn' may not be separated from the - `call_insn'. Stored in the `in_struct' field and printed as `/s'. - - These are the fields which the above macros refer to: - -`used' - Normally, this flag is used only momentarily, at the end of RTL - generation for a function, to count the number of times an - expression appears in insns. Expressions that appear more than - once are copied, according to the rules for shared structure - (*note Sharing::.). - - In a `symbol_ref', it indicates that an external declaration for - the symbol has already been written. - - In a `reg', it is used by the leaf register renumbering code to - ensure that each register is only renumbered once. - -`volatil' - This flag is used in `mem', `symbol_ref' and `reg' expressions and - in insns. In RTL dump files, it is printed as `/v'. - - In a `mem' expression, it is 1 if the memory reference is volatile. - Volatile memory references may not be deleted, reordered or - combined. - - In a `symbol_ref' expression, it is used for machine-specific - purposes. - - In a `reg' expression, it is 1 if the value is a user-level - variable. 0 indicates an internal compiler temporary. - - In an insn, 1 means the insn has been deleted. - -`in_struct' - In `mem' expressions, it is 1 if the memory datum referred to is - all or part of a structure or array; 0 if it is (or might be) a - scalar variable. A reference through a C pointer has 0 because - the pointer might point to a scalar variable. This information - allows the compiler to determine something about possible cases of - aliasing. - - In an insn in the delay slot of a branch, 1 means that this insn - is from the target of the branch. - - During instruction scheduling, in an insn, 1 means that this insn - must be scheduled as part of a group together with the previous - insn. - - In `reg' expressions, it is 1 if the register has its entire life - contained within the test expression of some loop. - - In `subreg' expressions, 1 means that the `subreg' is accessing an - object that has had its mode promoted from a wider mode. - - In `label_ref' expressions, 1 means that the referenced label is - outside the innermost loop containing the insn in which the - `label_ref' was found. - - In `code_label' expressions, it is 1 if the label may never be - deleted. This is used for labels which are the target of - non-local gotos. - - In an RTL dump, this flag is represented as `/s'. - -`unchanging' - In `reg' and `mem' expressions, 1 means that the value of the - expression never changes. - - In `subreg' expressions, it is 1 if the `subreg' references an - unsigned object whose mode has been promoted to a wider mode. - - In an insn, 1 means that this is an annulling branch. - - In a `symbol_ref' expression, 1 means that this symbol addresses - something in the per-function constants pool. - - In a `call_insn', 1 means that this instruction is a call to a - const function. - - In an RTL dump, this flag is represented as `/u'. - -`integrated' - In some kinds of expressions, including insns, this flag means the - rtl was produced by procedure integration. - - In a `reg' expression, this flag indicates the register containing - the value to be returned by the current function. On machines - that pass parameters in registers, the same register number may be - used for parameters as well, but this flag is not set on such uses. + GNU CC by itself attempts to be what the ISO/ANSI C standard calls a +"conforming freestanding implementation". This means all ANSI C +language features are available, as well as the contents of `float.h', +`limits.h', `stdarg.h', and `stddef.h'. The rest of the C library is +supplied by the vendor of the operating system. If that C library +doesn't conform to the C standards, then your programs might get +warnings (especially when using `-Wall') that you don't expect. + + For example, the `sprintf' function on SunOS 4.1.3 returns `char *' +while the C standard says that `sprintf' returns an `int'. The +`fixincludes' program could make the prototype for this function match +the Standard, but that would be wrong, since the function will still +return `char *'. + + If you need a Standard compliant library, then you need to find one, +as GNU CC does not provide one. The GNU C library (called `glibc') has +been ported to a number of operating systems, and provides ANSI/ISO, +POSIX, BSD and SystemV compatibility. You could also ask your operating +system vendor if newer libraries are available.  -File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL +File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble + +Disappointments and Misunderstandings +===================================== -Machine Modes -============= + These problems are perhaps regrettable, but we don't know any +practical way around them. - A machine mode describes a size of data object and the -representation used for it. In the C code, machine modes are -represented by an enumeration type, `enum machine_mode', defined in -`machmode.def'. Each RTL expression has room for a machine mode and so -do certain kinds of tree expressions (declarations and types, to be -precise). - - In debugging dumps and machine descriptions, the machine mode of an -RTL expression is written after the expression code with a colon to -separate them. The letters `mode' which appear at the end of each -machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' -expression with machine mode `SImode'. If the mode is `VOIDmode', it -is not written at all. - - Here is a table of machine modes. The term "byte" below refers to an -object of `BITS_PER_UNIT' bits (*note Storage Layout::.). - -`QImode' - "Quarter-Integer" mode represents a single byte treated as an - integer. - -`HImode' - "Half-Integer" mode represents a two-byte integer. - -`PSImode' - "Partial Single Integer" mode represents an integer which occupies - four bytes but which doesn't really use all four. On some - machines, this is the right mode to use for pointers. - -`SImode' - "Single Integer" mode represents a four-byte integer. - -`PDImode' - "Partial Double Integer" mode represents an integer which occupies - eight bytes but which doesn't really use all eight. On some - machines, this is the right mode to use for certain pointers. - -`DImode' - "Double Integer" mode represents an eight-byte integer. - -`TImode' - "Tetra Integer" (?) mode represents a sixteen-byte integer. - -`SFmode' - "Single Floating" mode represents a single-precision (four byte) - floating point number. - -`DFmode' - "Double Floating" mode represents a double-precision (eight byte) - floating point number. - -`XFmode' - "Extended Floating" mode represents a triple-precision (twelve - byte) floating point number. This mode is used for IEEE extended - floating point. - -`TFmode' - "Tetra Floating" mode represents a quadruple-precision (sixteen - byte) floating point number. - -`CCmode' - "Condition Code" mode represents the value of a condition code, - which is a machine-specific set of bits used to represent the - result of a comparison operation. Other machine-specific modes - may also be used for the condition code. These modes are not used - on machines that use `cc0' (see *note Condition Code::.). - -`BLKmode' - "Block" mode represents values that are aggregates to which none of - the other modes apply. In RTL, only memory references can have - this mode, and only if they appear in string-move or vector - instructions. On machines which have no such instructions, - `BLKmode' will not appear in RTL. - -`VOIDmode' - Void mode means the absence of a mode or an unspecified mode. For - example, RTL expressions of code `const_int' have mode `VOIDmode' - because they can be taken to have whatever mode the context - requires. In debugging dumps of RTL, `VOIDmode' is expressed by - the absence of any mode. - -`SCmode, DCmode, XCmode, TCmode' - These modes stand for a complex number represented as a pair of - floating point values. The floating point values are in `SFmode', - `DFmode', `XFmode', and `TFmode', respectively. - -`CQImode, CHImode, CSImode, CDImode, CTImode, COImode' - These modes stand for a complex number represented as a pair of - integer values. The integer values are in `QImode', `HImode', - `SImode', `DImode', `TImode', and `OImode', respectively. - - The machine description defines `Pmode' as a C macro which expands -into the machine mode used for addresses. Normally this is the mode -whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. - - The only modes which a machine description must support are -`QImode', and the modes corresponding to `BITS_PER_WORD', -`FLOAT_TYPE_SIZE' and `DOUBLE_TYPE_SIZE'. The compiler will attempt to -use `DImode' for 8-byte structures and unions, but this can be -prevented by overriding the definition of `MAX_FIXED_MODE_SIZE'. -Alternatively, you can have the compiler use `TImode' for 16-byte -structures and unions. Likewise, you can arrange for the C type `short -int' to avoid using `HImode'. - - Very few explicit references to machine modes remain in the compiler -and these few references will soon be removed. Instead, the machine -modes are divided into mode classes. These are represented by the -enumeration type `enum mode_class' defined in `machmode.h'. The -possible mode classes are: - -`MODE_INT' - Integer modes. By default these are `QImode', `HImode', `SImode', - `DImode', and `TImode'. - -`MODE_PARTIAL_INT' - The "partial integer" modes, `PSImode' and `PDImode'. - -`MODE_FLOAT' - floating point modes. By default these are `SFmode', `DFmode', - `XFmode' and `TFmode'. - -`MODE_COMPLEX_INT' - Complex integer modes. (These are not currently implemented). - -`MODE_COMPLEX_FLOAT' - Complex floating point modes. By default these are `SCmode', - `DCmode', `XCmode', and `TCmode'. - -`MODE_FUNCTION' - Algol or Pascal function variables including a static chain. - (These are not currently implemented). - -`MODE_CC' - Modes representing condition code values. These are `CCmode' plus - any modes listed in the `EXTRA_CC_MODES' macro. *Note Jump - Patterns::, also see *Note Condition Code::. - -`MODE_RANDOM' - This is a catchall mode class for modes which don't fit into the - above classes. Currently `VOIDmode' and `BLKmode' are in - `MODE_RANDOM'. - - Here are some C macros that relate to machine modes: - -`GET_MODE (X)' - Returns the machine mode of the RTX X. - -`PUT_MODE (X, NEWMODE)' - Alters the machine mode of the RTX X to be NEWMODE. - -`NUM_MACHINE_MODES' - Stands for the number of machine modes available on the target - machine. This is one greater than the largest numeric value of any - machine mode. - -`GET_MODE_NAME (M)' - Returns the name of mode M as a string. - -`GET_MODE_CLASS (M)' - Returns the mode class of mode M. - -`GET_MODE_WIDER_MODE (M)' - Returns the next wider natural mode. For example, the expression - `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. - -`GET_MODE_SIZE (M)' - Returns the size in bytes of a datum of mode M. - -`GET_MODE_BITSIZE (M)' - Returns the size in bits of a datum of mode M. - -`GET_MODE_MASK (M)' - Returns a bitmask containing 1 for all bits in a word that fit - within mode M. This macro can only be used for modes whose - bitsize is less than or equal to `HOST_BITS_PER_INT'. - -`GET_MODE_ALIGNMENT (M))' - Return the required alignment, in bits, for an object of mode M. - -`GET_MODE_UNIT_SIZE (M)' - Returns the size in bytes of the subunits of a datum of mode M. - This is the same as `GET_MODE_SIZE' except in the case of complex - modes. For them, the unit size is the size of the real or - imaginary part. - -`GET_MODE_NUNITS (M)' - Returns the number of units contained in a mode, i.e., - `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. - -`GET_CLASS_NARROWEST_MODE (C)' - Returns the narrowest mode in mode class C. - - The global variables `byte_mode' and `word_mode' contain modes whose -classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or -`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' -and `SImode', respectively. + * Certain local variables aren't recognized by debuggers when you + compile with optimization. + + This occurs because sometimes GNU CC optimizes the variable out of + existence. There is no way to tell the debugger how to compute the + value such a variable "would have had", and it is not clear that + would be desirable anyway. So GNU CC simply does not mention the + eliminated variable when it writes debugging information. + + You have to expect a certain amount of disagreement between the + executable and your source code, when you use optimization. + + * Users often think it is a bug when GNU CC reports an error for code + like this: + + int foo (struct mumble *); + + struct mumble { ... }; + + int foo (struct mumble *x) + { ... } + + This code really is erroneous, because the scope of `struct + mumble' in the prototype is limited to the argument list + containing it. It does not refer to the `struct mumble' defined + with file scope immediately below--they are two unrelated types + with similar names in different scopes. + + But in the definition of `foo', the file-scope type is used + because that is available to be inherited. Thus, the definition + and the prototype do not match, and you get an error. + + This behavior may seem silly, but it's what the ANSI standard + specifies. It is easy enough for you to make your code work by + moving the definition of `struct mumble' above the prototype. + It's not worth being incompatible with ANSI C just to avoid an + error for the example shown above. + + * Accesses to bitfields even in volatile objects works by accessing + larger objects, such as a byte or a word. You cannot rely on what + size of object is accessed in order to read or write the bitfield; + it may even vary for a given bitfield according to the precise + usage. + + If you care about controlling the amount of memory that is + accessed, use volatile but do not use bitfields. + + * GNU CC comes with shell scripts to fix certain known problems in + system header files. They install corrected copies of various + header files in a special directory where only GNU CC will + normally look for them. The scripts adapt to various systems by + searching all the system header files for the problem cases that + we know about. + + If new system header files are installed, nothing automatically + arranges to update the corrected header files. You will have to + reinstall GNU CC to fix the new header files. More specifically, + go to the build directory and delete the files `stmp-fixinc' and + `stmp-headers', and the subdirectory `include'; then do `make + install' again. + + * On 68000 systems, you can get paradoxical results if you test the + precise values of floating point numbers. For example, you can + find that a floating point value which is not a NaN is not equal + to itself. This results from the fact that the the floating point + registers hold a few more bits of precision than fit in a `double' + in memory. Compiled code moves values between memory and floating + point registers at its convenience, and moving them into memory + truncates them. + + You can partially avoid this problem by using the `-ffloat-store' + option (*note Optimize Options::.). + + * On the MIPS, variable argument functions using `varargs.h' cannot + have a floating point value for the first argument. The reason + for this is that in the absence of a prototype in scope, if the + first argument is a floating point, it is passed in a floating + point register, rather than an integer register. + + If the code is rewritten to use the ANSI standard `stdarg.h' + method of variable arguments, and the prototype is in scope at the + time of the call, everything will work fine.  -File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL +File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble -Constant Expression Types -========================= +Common Misunderstandings with GNU C++ +===================================== + + C++ is a complex language and an evolving one, and its standard +definition (the ANSI C++ draft standard) is also evolving. As a result, +your C++ compiler may occasionally surprise you, even when its behavior +is correct. This section discusses some areas that frequently give +rise to questions of this sort. + +* Menu: + +* Static Definitions:: Static member declarations are not definitions +* Temporaries:: Temporaries may vanish before you expect + + +File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings - The simplest RTL expressions are those that represent constant -values. +Declare *and* Define Static Members +----------------------------------- -`(const_int I)' - This type of expression represents the integer value I. I is - customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', - which is equivalent to `XWINT (EXP, 0)'. - - There is only one expression object for the integer value zero; it - is the value of the variable `const0_rtx'. Likewise, the only - expression for integer value one is found in `const1_rtx', the only - expression for integer value two is found in `const2_rtx', and the - only expression for integer value negative one is found in - `constm1_rtx'. Any attempt to create an expression of code - `const_int' and value zero, one, two or negative one will return - `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as - appropriate. - - Similarly, there is only one object for the integer whose value is - `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If - `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will - point to the same object. If `STORE_FLAG_VALUE' is -1, - `const_true_rtx' and `constm1_rtx' will point to the same object. - -`(const_double:M ADDR I0 I1 ...)' - Represents either a floating-point constant of mode M or an - integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' - bits but small enough to fit within twice that number of bits (GNU - CC does not provide a mechanism to represent even larger - constants). In the latter case, M will be `VOIDmode'. - - ADDR is used to contain the `mem' expression that corresponds to - the location in memory that at which the constant can be found. If - it has not been allocated a memory location, but is on the chain - of all `const_double' expressions in this compilation (maintained - using an undisplayed field), ADDR contains `const0_rtx'. If it is - not on the chain, ADDR contains `cc0_rtx'. ADDR is customarily - accessed with the macro `CONST_DOUBLE_MEM' and the chain field via - `CONST_DOUBLE_CHAIN'. - - If M is `VOIDmode', the bits of the value are stored in I0 and I1. - I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and - I1 with `CONST_DOUBLE_HIGH'. - - If the constant is floating point (regardless of its precision), - then the number of integers used to store the value depends on the - size of `REAL_VALUE_TYPE' (*note Cross-compilation::.). The - integers represent a floating point number, but not precisely in - the target machine's or host machine's floating point format. To - convert them to the precise bit pattern used by the target - machine, use the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends - (*note Data Output::.). - - The macro `CONST0_RTX (MODE)' refers to an expression with value 0 - in mode MODE. If mode MODE is of mode class `MODE_INT', it - returns `const0_rtx'. Otherwise, it returns a `CONST_DOUBLE' - expression in mode MODE. Similarly, the macro `CONST1_RTX (MODE)' - refers to an expression with value 1 in mode MODE and similarly - for `CONST2_RTX'. - -`(const_string STR)' - Represents a constant string with value STR. Currently this is - used only for insn attributes (*note Insn Attributes::.) since - constant strings in C are placed in memory. - -`(symbol_ref:MODE SYMBOL)' - Represents the value of an assembler label for data. SYMBOL is a - string that describes the name of the assembler label. If it - starts with a `*', the label is the rest of SYMBOL not including - the `*'. Otherwise, the label is SYMBOL, usually prefixed with - `_'. - - The `symbol_ref' contains a mode, which is usually `Pmode'. - Usually that is the only mode for which a symbol is directly valid. - -`(label_ref LABEL)' - Represents the value of an assembler label for code. It contains - one operand, an expression, which must be a `code_label' that - appears in the instruction sequence to identify the place where - the label should go. - - The reason for using a distinct expression type for code label - references is so that jump optimization can distinguish them. - -`(const:M EXP)' - Represents a constant that is the result of an assembly-time - arithmetic computation. The operand, EXP, is an expression that - contains only constants (`const_int', `symbol_ref' and `label_ref' - expressions) combined with `plus' and `minus'. However, not all - combinations are valid, since the assembler cannot do arbitrary - arithmetic on relocatable symbols. - - M should be `Pmode'. - -`(high:M EXP)' - Represents the high-order bits of EXP, usually a `symbol_ref'. - The number of bits is machine-dependent and is normally the number - of bits specified in an instruction that initializes the high - order bits of a register. It is used with `lo_sum' to represent - the typical two-instruction sequence used in RISC machines to - reference a global memory location. + When a class has static data members, it is not enough to *declare* +the static member; you must also *define* it. For example: - M should be `Pmode'. + class Foo + { + ... + void method(); + static int bar; + }; + + This declaration only establishes that the class `Foo' has an `int' +named `Foo::bar', and a member function named `Foo::method'. But you +still need to define *both* `method' and `bar' elsewhere. According to +the draft ANSI standard, you must supply an initializer in one (and +only one) source file, such as: + + int Foo::bar = 0; + + Other C++ compilers may not correctly implement the standard +behavior. As a result, when you switch to `g++' from one of these +compilers, you may discover that a program that appeared to work +correctly in fact does not conform to the standard: `g++' reports as +undefined symbols any static data members that lack definitions.