--- gcc/gcc.info-11 2018/04/24 17:52:34 1.1.1.2 +++ gcc/gcc.info-11 2018/04/24 18:25:05 1.1.1.8 @@ -1,1175 +1,1144 @@ -This is Info file gcc.info, produced by Makeinfo-1.44 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. - Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. + Published by the Free Software Foundation 59 Temple Place - Suite 330 +Boston, MA 02111-1307 USA - Permission is granted to make and distribute verbatim copies of -this manual provided the copyright notice and this permission notice -are preserved on all copies. + 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 +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 section entitled "GNU General Public License" is 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 section entitled "GNU General Public -License" and this permission notice may be included in translations -approved by the Free Software Foundation instead of in the original -English. +versions, except that the sections entitled "GNU General Public +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: Insn Canonicalizations, Next: Peephole Definitions, Prev: Jump Patterns, Up: Machine Desc +File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble -Canonicalization of Instructions -================================ +Installation Problems +===================== - There are often cases where multiple RTL expressions could -represent an operation performed by a single machine instruction. -This situation is most commonly encountered with logical, branch, and -multiply-accumulate instructions. In such cases, the compiler -attempts to convert these multiple RTL expressions into a single -canonical form to reduce the number of insn patterns required. - - In addition to algebraic simplifications, following -canonicalizations are performed: - - * For commutative and comparison operators, a constant is always - made the second operand. If a machine only supports a constant - as the second operand, only patterns that match a constant in the - second operand need be supplied. - - For these operators, if only one operand is a `neg', `not', - `mult', `plus', or `minus' expression, it will be the first - operand. - - * For the `compare' operator, a constant is always the second - operand on machines where `cc0' is used (*note Jump Patterns::.). - On other machines, there are rare cases where the compiler might - want to construct a `compare' with a constant as the first - operand. However, these cases are not common enough for it to be - worthwhile to provide a pattern matching a constant as the first - operand unless the machine actually has such an instruction. - - An operand of `neg', `not', `mult', `plus', or `minus' is made - the first operand under the same conditions as above. - - * `(minus X (const_int N))' is converted to `(plus X (const_int - -N))'. - - * Within address computations (i.e., inside `mem'), a left shift is - converted into the appropriate multiplication by a power of two. - - De`Morgan's Law is used to move bitwise negation inside a bitwise - logical-and or logical-or operation. If this results in only one - operand being a `not' expression, it will be the first one. - - A machine that has an instruction that performs a bitwise - logical-and of one operand with the bitwise negation of the other - should specify the pattern for that instruction as - - (define_insn "" - [(set (match_operand:M 0 ...) - (and:M (not:M (match_operand:M 1 ...)) - (match_operand:M 2 ...)))] - "..." - "...") - - Similarly, a pattern for a "NAND" instruction should be written - - (define_insn "" - [(set (match_operand:M 0 ...) - (ior:M (not:M (match_operand:M 1 ...)) - (not:M (match_operand:M 2 ...))))] - "..." - "...") - - In both cases, it is not necessary to include patterns for the - many logically equivalent RTL expressions. - - * The only possible RTL expressions involving both bitwise - exclusive-or and bitwise negation are `(xor:M X) Y)' and `(not:M - (xor:M X Y))'. - - * The sum of three items, one of which is a constant, will only - appear in the form - - (plus:M (plus:M X Y) CONSTANT) - - * On machines that do not use `cc0', `(compare X (const_int 0))' - will be converted to X. - - * Equality comparisons of a group of bits (usually a single bit) - with zero will be written using `zero_extract' rather than the - equivalent `and' or `sign_extract' operations. + 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. - -File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Insn Canonicalizations, Up: Machine Desc + * On certain systems, defining certain environment variables such as + `CC' can interfere with the functioning of `make'. -Defining Machine-Specific Peephole Optimizers -============================================= + * 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::. - In addition to instruction patterns the `md' file may contain -definitions of machine-specific peephole optimizations. + * 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 combiner does not notice certain peephole optimizations when -the data flow in the program does not suggest that it should try them. - For example, sometimes two consecutive insns related in purpose can -be combined even though the second one does not appear to use a -register computed in the first one. A machine-specific peephole -optimizer can detect such opportunities. - - A definition looks like this: - - (define_peephole - [INSN-PATTERN-1 - INSN-PATTERN-2 - ...] - "CONDITION" - "TEMPLATE" - "OPTIONAL INSN-ATTRIBUTES") - -The last string operand may be omitted if you are not using any -machine-specific information in this machine description. If present, -it must obey the same rules as in a `define_insn'. - - In this skeleton, INSN-PATTERN-1 and so on are patterns to match -consecutive insns. The optimization applies to a sequence of insns -when INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the -next, and so on. - - Each of the insns matched by a peephole must also match a -`define_insn'. Peepholes are checked only at the last stage just -before code generation, and only optionally. Therefore, any insn which -would match a peephole but no `define_insn' will cause a crash in code -generation in an unoptimized compilation, or at various optimization -stages. - - The operands of the insns are matched with `match_operands', -`match_operator', and `match_dup', as usual. What is not usual is -that the operand numbers apply to all the insn patterns in the -definition. So, you can check for identical operands in two insns by -using `match_operand' in one insn and `match_dup' in the other. - - The operand constraints used in `match_operand' patterns do not have -any direct effect on the applicability of the peephole, but they will -be validated afterward, so make sure your constraints are general -enough to apply whenever the peephole matches. If the peephole matches -but the constraints are not satisfied, the compiler will crash. - - It is safe to omit constraints in all the operands of the peephole; -or you can write constraints which serve as a double-check on the -criteria previously tested. - - Once a sequence of insns matches the patterns, the CONDITION is -checked. This is a C expression which makes the final decision -whether to perform the optimization (we do so if the expression is -nonzero). If CONDITION is omitted (in other words, the string is -empty) then the optimization is applied to every sequence of insns -that matches the patterns. - - The defined peephole optimizations are applied after register -allocation is complete. Therefore, the peephole definition can check -which operands have ended up in which kinds of registers, just by -looking at the operands. - - The way to refer to the operands in CONDITION is to write -`operands[I]' for operand number I (as matched by `(match_operand I -...)'). Use the variable `insn' to refer to the last of the insns -being matched; use `prev_nonnote_insn' to find the preceding insns. - - When optimizing computations with intermediate results, you can use -CONDITION to match only when the intermediate results are not used -elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where -INSN is the insn in which you expect the value to be used for the last -time (from the value of `insn', together with use of -`prev_nonnote_insn'), and OP is the intermediate value (from -`operands[I]'). - - Applying the optimization means replacing the sequence of insns -with one new insn. The TEMPLATE controls ultimate output of assembler -code for this combined insn. It works exactly like the template of a -`define_insn'. Operand numbers in this template are the same ones -used in matching the original sequence of insns. - - The result of a defined peephole optimizer does not need to match -any of the insn patterns in the machine description; it does not even -have an opportunity to match them. The peephole optimizer definition -itself serves as the insn pattern to control how the insn is output. - - Defined peephole optimizers are run as assembler code is being -output, so the insns they produce are never combined or rearranged in -any way. - - Here is an example, taken from the 68000 machine description: - - (define_peephole - [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) - (set (match_operand:DF 0 "register_operand" "f") - (match_operand:DF 1 "register_operand" "ad"))] - "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" - "* - { - rtx xoperands[2]; - xoperands[1] = gen_rtx (REG, SImode, REGNO (operands[1]) + 1); - #ifdef MOTOROLA - output_asm_insn (\"move.l %1,(sp)\", xoperands); - output_asm_insn (\"move.l %1,-(sp)\", operands); - return \"fmove.d (sp)+,%0\"; - #else - output_asm_insn (\"movel %1,sp@\", xoperands); - output_asm_insn (\"movel %1,sp@-\", operands); - return \"fmoved sp@+,%0\"; - #endif - } - ") - - The effect of this optimization is to change - - jbsr _foobar - addql #4,sp - movel d1,sp@- - movel d0,sp@- - fmoved sp@+,fp0 - -into - - jbsr _foobar - movel d1,sp@ - movel d0,sp@- - fmoved sp@+,fp0 - - INSN-PATTERN-1 and so on look *almost* like the second operand of -`define_insn'. There is one important difference: the second operand -of `define_insn' consists of one or more RTX's enclosed in square -brackets. Usually, there is only one: then the same action can be -written as an element of a `define_peephole'. But when there are -multiple actions in a `define_insn', they are implicitly enclosed in a -`parallel'. Then you must explicitly write the `parallel', and the -square brackets within it, in the `define_peephole'. Thus, if an insn -pattern looks like this, - - (define_insn "divmodsi4" - [(set (match_operand:SI 0 "general_operand" "=d") - (div:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "dmsK"))) - (set (match_operand:SI 3 "general_operand" "=d") - (mod:SI (match_dup 1) (match_dup 2)))] - "TARGET_68020" - "divsl%.l %2,%3:%0") - -then the way to mention this insn in a peephole is as follows: - - (define_peephole - [... - (parallel - [(set (match_operand:SI 0 "general_operand" "=d") - (div:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "dmsK"))) - (set (match_operand:SI 3 "general_operand" "=d") - (mod:SI (match_dup 1) (match_dup 2)))]) - ...] - ...) + The solution is not to use such a directory for building GNU CC. - -File: gcc.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Peephole Definitions, Up: Machine Desc + * 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'. -Defining RTL Sequences for Code Generation -========================================== + 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). - On some target machines, some standard pattern names for RTL -generation cannot be handled with single insn, but a sequence of RTL -insns can represent them. For these target machines, you can write a -`define_expand' to specify how to generate the sequence of RTL. - - A `define_expand' is an RTL expression that looks almost like a -`define_insn'; but, unlike the latter, a `define_expand' is used only -for RTL generation and it can produce more than one RTL insn. - - A `define_expand' RTX has four operands: - - * The name. Each `define_expand' must have a name, since the only - use for it is to refer to it by name. - - * The RTL template. This is just like the RTL template for a - `define_peephole' in that it is a vector of RTL expressions each - being one insn. - - * The condition, a string containing a C expression. This - expression is used to express how the availability of this - pattern depends on subclasses of target machine, selected by - command-line options when GNU CC is run. This is just like the - condition of a `define_insn' that has a standard name. - - * The preparation statements, a string containing zero or more C - statements which are to be executed before RTL code is generated - from the RTL template. - - Usually these statements prepare temporary registers for use as - internal operands in the RTL template, but they can also generate - RTL insns directly by calling routines such as `emit_insn', etc. - Any such insns precede the ones that come from the RTL template. - - Every RTL insn emitted by a `define_expand' must match some -`define_insn' in the machine description. Otherwise, the compiler -will crash when trying to generate code for the insn or trying to -optimize it. - - The RTL template, in addition to controlling generation of RTL -insns, also describes the operands that need to be specified when this -pattern is used. In particular, it gives a predicate for each operand. - - A true operand, which needs to be specified in order to generate -RTL from the pattern, should be described with a `match_operand' in -its first occurrence in the RTL template. This enters information on -the operand's predicate into the tables that record such things. GNU -CC uses the information to preload the operand into a register if that -is required for valid RTL code. If the operand is referred to more -than once, subsequent references should use `match_dup'. - - The RTL template may also refer to internal "operands" which are -temporary registers or labels used only within the sequence made by the -`define_expand'. Internal operands are substituted into the RTL -template with `match_dup', never with `match_operand'. The values of -the internal operands are not passed in as arguments by the compiler -when it requests use of this pattern. Instead, they are computed -within the pattern, in the preparation statements. These statements -compute the values and store them into the appropriate elements of -`operands' so that `match_dup' can find them. - - There are two special macros defined for use in the preparation -statements: `DONE' and `FAIL'. Use them with a following semicolon, -as a statement. - -`DONE' - Use the `DONE' macro to end RTL generation for the pattern. The - only RTL insns resulting from the pattern on this occasion will be - those already emitted by explicit calls to `emit_insn' within the - preparation statements; the RTL template will not be generated. - -`FAIL' - Make the pattern fail on this occasion. When a pattern fails, it - means that the pattern was not truly available. The calling - routines in the compiler will try other strategies for code - generation using other patterns. - - Failure is currently supported only for binary (addition, - multiplication, shifting, etc.) and bitfield (`extv', `extzv', - and `insv') operations. - - Here is an example, the definition of left-shift for the SPUR chip: - - (define_expand "ashlsi3" - [(set (match_operand:SI 0 "register_operand" "") - (ashift:SI - (match_operand:SI 1 "register_operand" "") - (match_operand:SI 2 "nonmemory_operand" "")))] - "" - " - { - if (GET_CODE (operands[2]) != CONST_INT - || (unsigned) INTVAL (operands[2]) > 3) - FAIL; - }") - -This example uses `define_expand' so that it can generate an RTL insn -for shifting when the shift-count is in the supported range of 0 to 3 -but fail in other cases where machine insns aren't available. When it -fails, the compiler tries another strategy using different patterns -(such as, a library call). - - If the compiler were able to handle nontrivial condition-strings in -patterns with names, then it would be possible to use a `define_insn' -in that case. Here is another case (zero-extension on the 68000) -which makes more use of the power of `define_expand': - - (define_expand "zero_extendhisi2" - [(set (match_operand:SI 0 "general_operand" "") - (const_int 0)) - (set (strict_low_part - (subreg:HI - (match_dup 0) - 0)) - (match_operand:HI 1 "general_operand" ""))] - "" - "operands[1] = make_safe_from (operands[1], operands[0]);") - -Here two RTL insns are generated, one to clear the entire output -operand and the other to copy the input operand into its low half. -This sequence is incorrect if the input operand refers to [the old -value of] the output operand, so the preparation statement makes sure -this isn't so. The function `make_safe_from' copies the `operands[1]' -into a temporary register if it refers to `operands[0]'. It does this -by emitting another RTL insn. - - Finally, a third example shows the use of an internal operand. -Zero-extension on the SPUR chip is done by `and'-ing the result -against a halfword mask. But this mask cannot be represented by a -`const_int' because the constant value is too large to be legitimate -on this machine. So it must be copied into a register with -`force_reg' and then the register used in the `and'. - - (define_expand "zero_extendhisi2" - [(set (match_operand:SI 0 "register_operand" "") - (and:SI (subreg:SI - (match_operand:HI 1 "register_operand" "") - 0) - (match_dup 2)))] - "" - "operands[2] - = force_reg (SImode, gen_rtx (CONST_INT, - VOIDmode, 65535)); ") - - *Note:* If the `define_expand' is used to serve a standard binary -or unary arithmetic operation or a bitfield operation, then the last -insn it generates must not be a `code_label', `barrier' or `note'. It -must be an `insn', `jump_insn' or `call_insn'. If you don't need a -real insn at the end, emit an insn to copy the result of the operation -into itself. Such an insn will generate no code, but it can avoid -problems in the compiler. + * 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. - -File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc + * 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. -Splitting Instructions into Multiple Instructions -================================================= + * 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. - On machines that have instructions requiring delay slots (*note -Delay Slots::.) or that have instructions whose output is not -available for multiple cycles (*note Function Units::.), the compiler -phases that optimize these cases need to be able to move insns into -one-cycle delay slots. However, some insns may generate more than one -machine instruction. These insns would be unable to be placed into a -delay slot. - - It is often possible to write the single insn as a list of -individual insns, each corresponding to one machine instruction. The -disadvantage of doing so is that it will cause the compilation to be -slower and require more space. If the resulting insns are too -complex, it may also suppress some optimizations. - - The `define_split' definition tells the compiler how to split a -complex insn into several simpler insns. This spilling will be -performed if there is a reason to believe that it might improve -instruction or delay slot scheduling. The definition looks like this: - - (define_split - [INSN-PATTERN] - "CONDITION" - [NEW-INSN-PATTERN-1 - NEW-INSN-PATTERN-2 - ...] - "PREPARATION STATEMENTS") - - INSN-PATTERN is a pattern that needs to be split and CONDITION is -the final condition to be tested, as in a `define_insn'. Any insn -matched by a `define_split' must also be matched by a `define_insn' in -case it does not need to be split. - - When an insn matching INSN-PATTERN and satisfying CONDITION is -found, it is replaced in the insn list with the insns given by -NEW-INSN-PATTERN-1, NEW-INSN-PATTERN-2, etc. - - The PREPARATION STATEMENTS are similar to those specified for -`define_expand' (*note Expander Definitions::.) and are executed -before the new RTL is generated to prepare for the generated code or -emit some insns whose pattern is not fixed. - - As a simple case, consider the following example from the AMD 29000 -machine description, which splits a `sign_extend' from `HImode' to -`SImode' into a pair of shift insns: - - (define_split - [(set (match_operand:SI 0 "gen_reg_operand" "") - (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] - "" - [(set (match_dup 0) - (ashift:SI (match_dup 1) - (const_int 16))) - (set (match_dup 0) - (ashiftrt:SI (match_dup 0) - (const_int 16)))] - " - { operands[1] = gen_lowpart (SImode, operands[1]); }") + * 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. - -File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc + * 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'. -Instruction Attributes -====================== + * 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. - In addition to describing the instruction supported by the target -machine, the `md' file also defines a group of "attributes" and a set -of values for each. Every generated insn is assigned a value for each -attribute. One possible attribute would be the effect that the insn -has on the machine's condition code. This attribute can then be used -by `NOTICE_UPDATE_CC' to track the condition codes. + 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'. -* Menu: + * 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. -* Defining Attributes:: Specifying attributes and their values. -* Expressions:: Valid expressions for attribute values. -* Tagging Insns:: Assigning attribute values to insns. -* Attr Example:: An example of assigning attributes. -* Insn Lengths:: Computing the length of insns. -* Constant Attributes:: Defining attributes that are constant. -* Delay Slots:: Defining delay slots required for a machine. -* Function Units:: Specifying information for insn scheduling. + 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: - -File: gcc.info, Node: Defining Attributes, Next: Expressions, Prev: Insn Attributes, Up: Insn Attributes + 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 -Defining Attributes and their Values ------------------------------------- + that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'. - The `define_attr' expression is used to define each attribute -required by the target machine. It looks like: + * Current GNU CC versions probably do not work on version 2 of the + NeXT operating system. - (define_attr NAME LIST-OF-VALUES DEFAULT) + * 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. - NAME is a string specifying the name of the attribute being defined. + * 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. - LIST-OF-VALUES is either a string that specifies a comma-separated -list of values that can be assigned to the attribute, or a null string -to indicate that the attribute takes numeric values. + To solve this problem, reconfigure the kernel adding the following + line to the configuration file: - DEFAULT is an attribute expression that gives the value of this -attribute for insns that match patterns whose definition does not -include an explicit value for this attribute. *Note Attr Example::, -for more information on the handling of defaults. *Note Constant -Attributes::, for information on attributes that do not depend on any -particular insn. + MAXUMEM = 4096 - For each defined attribute, a number of definitions are written to -the `insn-attr.h' file. For cases where an explicit set of values is -specified for an attribute, the following are defined: + * 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': - * A `#define' is written for the symbol `HAVE_ATTR_NAME'. + _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 - * An enumeral class is defined for `attr_NAME' with elements of the - form `UPPER-NAME_UPPER-VALUE' where the attribute name and value - are first converted to upper case. + 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: - * A function `get_attr_NAME' is defined that is passed an insn and - returns the attribute value for that insn. + This is the patched assembler, to patch SR#1653-010439, where + the assembler aborts on floating point constants. - For example, if the following is present in the `md' file: + 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. - (define_attr "type" "branch,fp,load,store,arith" ...) + This patch is also known as PHCO_4484. -the following lines will be written to the file `insn-attr.h'. + * 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'. - #define HAVE_ATTR_type - enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, - TYPE_STORE, TYPE_ARITH}; - extern enum attr_type get_attr_type (); + * 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'. - If the attribute takes numeric values, no `enum' type will be -defined and the function to obtain the attribute's value will return -`int'. + 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: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes +File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble + +Cross-Compiler Problems +======================= -Attribute Expressions ---------------------- + You may run into problems with cross compilation on certain machines, +for several reasons. - RTL expressions used to define attributes use the codes described -above plus a few specific to attribute definitions, to be discussed -below. Attribute value expressions must have one of the following -forms: - -`(const_int I)' - The integer I specifies the value of a numeric attribute. I must - be non-negative. - - The value of a numeric attribute can be specified either with a - `const_int' or as an integer represented as a string in - `const_string', `eq_attr' (see below), and `set_attr' (*note - Tagging Insns::.) expressions. - -`(const_string VALUE)' - The string VALUE specifies a constant attribute value. If VALUE - is specified as `"*"', it means that the default value of the - attribute is to be used for the insn containing this expression. - `"*"' obviously cannot be used in the DEFAULT expression of a - `define_attr'. - - If the attribute whose value is being specified is numeric, VALUE - must be a string containing a non-negative integer (normally - `const_int' would be used in this case). Otherwise, it must - contain one of the valid values for the attribute. - -`(if_then_else TEST TRUE-VALUE FALSE-VALUE)' - TEST specifies an attribute test, whose format is defined below. - The value of this expression is TRUE-VALUE if TEST is true, - otherwise it is FALSE-VALUE. - -`(cond [TEST1 VALUE1 ...] DEFAULT)' - The first operand of this expression is a vector containing an - even number of expressions and consisting of pairs of TEST and - VALUE expressions. The value of the `cond' expression is that of - the VALUE corresponding to the first true TEST expression. If - none of the TEST expressions are true, the value of the `cond' - expression is that of the DEFAULT expression. - - TEST expressions can have one of the following forms: - -`(const_int I)' - This test is true if I is non-zero and false otherwise. - -`(not TEST)' -`(ior TEST1 TEST2)' -`(and TEST1 TEST2)' - These tests are true if the indicated logical function is true. - -`(match_operand:M N PRED CONSTRAINTS)' - This test is true if operand N of the insn whose attribute value - is being determined has mode M (this part of the test is ignored - if M is `VOIDmode') and the function specified by the string PRED - returns a non-zero value when passed operand N and mode M (this - part of the test is ignored if PRED is the null string). - - The CONSTRAINTS operand is ignored and should be the null string. - -`(le ARITH1 ARITH2)' -`(leu ARITH1 ARITH2)' -`(lt ARITH1 ARITH2)' -`(ltu ARITH1 ARITH2)' -`(gt ARITH1 ARITH2)' -`(gtu ARITH1 ARITH2)' -`(ge ARITH1 ARITH2)' -`(geu ARITH1 ARITH2)' -`(ne ARITH1 ARITH2)' -`(eq ARITH1 ARITH2)' - These tests are true if the indicated comparison of the two - arithmetic expressions is true. Arithmetic expressions are - formed with `plus', `minus', `mult', `div', `mod', `abs', `neg', - `and', `ior', `xor', `not', `lshift', `ashift', `lshiftrt', and - `ashiftrt' expressions. - - `const_int' and `symbol_ref' are always valid terms (*note Insn - Lengths::.,for additional forms). `symbol_ref' is a string - denoting a C expression that yields an `int' when evaluated by the - `get_attr_...' routine. It should normally be a global variable. - -`(eq_attr NAME VALUE)' - NAME is a string specifying the name of an attribute. - - VALUE is a string that is either a valid value for attribute - NAME, a comma-separated list of values, or `!' followed by a - value or list. If VALUE does not begin with a `!', this test is - true if the value of the NAME attribute of the current insn is in - the list specified by VALUE. If VALUE begins with a `!', this - test is true if the attribute's value is *not* in the specified - list. - - For example, - - (eq_attr "type" "load,store") - - is equivalent to - - (ior (eq_attr "type" "load") (eq_attr "type" "store")) - - If NAME specifies an attribute of `alternative', it refers to the - value of the compiler variable `which_alternative' (*note Output - Statement::.) and the values must be small integers. For example, - - (eq_attr "alternative" "2,3") - - is equivalent to - - (ior (eq (symbol_ref "which_alternative") (const_int 2)) - (eq (symbol_ref "which_alternative") (const_int 3))) - - Note that, for most attributes, an `eq_attr' test is simplified - in cases where the value of the attribute being tested is known - for all insns matching a particular pattern. This is by far the - most common case. + * Cross compilation can run into trouble for certain machines because + some target machines' assemblers require floating point numbers to + be written as *integer* constants in certain contexts. + + The compiler writes these integer constants by examining the + floating point value as an integer and printing that integer, + because this is simple to write and independent of the details of + the floating point representation. But this does not work if the + compiler is running on a different machine with an incompatible + floating point format, or even a different byte-ordering. + + In addition, correct constant folding of floating point values + requires representing them in the target machine's format. (The C + standard does not quite require this, but in practice it is the + only way to win.) + + It is now possible to overcome these problems by defining macros + such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of + work for each target machine. *Note Cross-compilation::. + + * At present, the program `mips-tfile' which adds debug support to + object files on MIPS systems does not work in a cross compile + environment.  -File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes +File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble -Assigning Attribute Values to Insns ------------------------------------ +Interoperation +============== - The value assigned to an attribute of an insn is primarily -determined by which pattern is matched by that insn (or which -`define_peephole' generated it). Every `define_insn' and -`define_peephole' can have an optional last argument to specify the -values of attributes for matching insns. The value of any attribute -not specified in a particular insn is set to the default value for -that attribute, as specified in its `define_attr'. Extensive use of -default values for attributes permits the specification of the values -for only one or two attributes in the definition of most insn -patterns, as seen in the example in the next section. - - The optional last argument of `define_insn' and `define_peephole' -is a vector of expressions, each of which defines the value for a -single attribute. The most general way of assigning an attribute's -value is to use a `set' expression whose first operand is an `attr' -expression giving the name of the attribute being set. The second -operand of the `set' is an attribute expression (*note Expressions::.) -giving the value of the attribute. - - When the attribute value depends on the `alternative' attribute -(i.e., which is the applicable alternative in the constraint of the -insn), the `set_attr_alternative' expression can can be used. It -allows the specification of a vector of attribute expressions, one for -each alternative. - - When the generality of arbitrary attribute expressions is not -required, the simpler `set_attr' expression can be used, which allows -specifying a string giving either a single attribute value or a list -of attribute values, one for each alternative. - - The form of each of the above specifications is shown below. In -each case, NAME is a string specifying the attribute to be set. - -`(set_attr NAME VALUE-STRING)' - VALUE-STRING is either a string giving the desired attribute - value, or a string containing a comma-separated list giving the - values for succeeding alternatives. The number of elements must - match the number of alternatives in the constraint of the insn - pattern. - - Note that it may be useful to specify `*' for some alternative, in - which case the attribute will assume its default value for insns - matching that alternative. - -`(set_attr_alternative NAME [VALUE1 VALUE2 ...])' - Depending on the alternative of the insn, the value will be one - of the specified values. This is a shorthand for using a `cond' - with tests on the `alternative' attribute. - -`(set (attr NAME) VALUE)' - The first operand of this `set' must be the special RTL expression - `attr', whose sole operand is a string giving the name of the - attribute being set. VALUE is the value of the attribute. - - The following shows three different ways of representing the same -attribute value specification: - - (set_attr "type" "load,store,arith") - - (set_attr_alternative "type" - [(const_string "load") (const_string "store") - (const_string "arith")]) - - (set (attr "type") - (cond [(eq_attr "alternative" "1") (const_string "load") - (eq_attr "alternative" "2") (const_string "store")] - (const_string "arith"))) - - The `define_asm_attributes' expression provides a mechanism to -specify the attributes assigned to insns produced from an `asm' -statement. It has the form: - - (define_asm_attributes [ATTR-SETS]) - -where ATTR-SETS is specified the same as for `define_insn' and -`define_peephole' expressions. - - These values will typically be the "worst case" attribute values. -For example, they might indicate that the condition code will be -clobbered. - - A specification for a `length' attribute is handled specially. To -compute the length of an `asm' insn, the length specified in the -`define_asm_attributes' expression is multiplied by the number of -machine instructions specified in the `asm' statement, determined by -counting the number of semicolons and newlines in the string. -Therefore, the value of the `length' attribute specified in a -`define_asm_attributes' should be the maximum possible length of a -single machine instruction. + 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: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes +File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble -Example of Attribute Specifications ------------------------------------ +Problems Compiling Certain Programs +=================================== - The judicious use of defaulting is important in the efficient use of -insn attributes. Typically, insns are divided into "types" and an -attribute, customarily called `type', is used to represent this value. - This attribute is normally used only to define the default value for -other attributes. An example will clarify this usage. - - Assume we have a RISC machine with a condition code and in which -only full-word operations are performed in registers. Let us assume -that we can divide all insns into loads, stores, (integer) arithmetic -operations, floating point operations, and branches. - - Here we will concern ourselves with determining the effect of an -insn on the condition code and will limit ourselves to the following -possible effects: The condition code can be set unpredictably -(clobbered), not be changed, be set to agree with the results of the -operation, or only changed if the item previously set into the -condition code has been modified. - - Here is part of a sample `md' file for such a machine: - - (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) - - (define_attr "cc" "clobber,unchanged,set,change0" - (cond [(eq_attr "type" "load") - (const_string "change0") - (eq_attr "type" "store,branch") - (const_string "unchanged") - (eq_attr "type" "arith") - (if_then_else (match_operand:SI 0 "" "") - (const_string "set") - (const_string "clobber"))] - (const_string "clobber"))) - - (define_insn "" - [(set (match_operand:SI 0 "general_operand" "=r,r,m") - (match_operand:SI 1 "general_operand" "r,m,r"))] - "" - "@ - move %0,%1 - load %0,%1 - store %0,%1" - [(set_attr "type" "arith,load,store")]) - - Note that we assume in the above example that arithmetic operations -performed on quantities smaller than a machine word clobber the -condition code since they will set the condition code to a value -corresponding to the full-word result. + 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 + + -traditional -Dvolatile=__volatile__ + -I/usr/include/sun -I/usr/ucbinclude + -fpcc-struct-return + + 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'. + + * 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: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes +File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble -Computing the Length of an Insn -------------------------------- +Incompatibilities of GNU CC +=========================== - For many machines, multiple types of branch instructions are -provided, each for different length branch displacements. In most -cases, the assembler will choose the correct instruction to use. -However, when the assembler cannot do so, GCC can when a special -attribute, the `length' attribute, is defined. This attribute must be -defined to have numeric values by specifying a null string in its -`define_attr'. - - In the case of the `length' attribute, two additional forms of -arithmetic terms are allowed in test expressions: - -`(match_dup N)' - This refers to the address of operand N of the current insn, which - must be a `label_ref'. - -`(pc)' - This refers to the address of the *current* insn. It might have - been more consistent with other usage to make this the address of - the *next* insn but this would be confusing because the length of - the current insn is to be computed. - - For normal insns, the length will be determined by value of the -`length' attribute. In the case of `addr_vec' and `addr_diff_vec' -insn patterns, the length will be computed as the number of vectors -multiplied by the size of each vector. - - The following macros can be used to refine the length computation: - -`FIRST_INSN_ADDRESS' - When the `length' insn attribute is used, this macro specifies the - value to be assigned to the address of the first insn in a - function. If not specified, 0 is used. - -`ADJUST_INSN_LENGTH (INSN, LENGTH)' - If defined, modifies the length assigned to instruction INSN as a - function of the context in which it is used. LENGTH is an lvalue - that contains the initially computed length of the insn and - should be updated with the correct length of the insn. If - updating is required, INSN must not be a varying-length insn. - - This macro will normally not be required. A case in which it is - required is the ROMP. On this machine, the size of an `addr_vec' - insn must be increased by two to compensate for the fact that - alignment may be required. - - The routine that returns the value of the `length' attribute, -`get_attr_length', can be used by the output routine to determine the -form of the branch instruction to be written, as the example below -illustrates. - - As an example of the specification of variable-length branches, -consider the IBM 360. If we adopt the convention that a register will -be set to the starting address of a function, we can jump to labels -within 4K of the start using a four-byte instruction. Otherwise, we -need a six-byte sequence to load the address from memory and then -branch to it. - - On such a machine, a pattern for a branch instruction might be -specified as follows: - - (define_insn "jump" - [(set (pc) - (label_ref (match_operand 0 "" "")))] - "" - "* - { - return (get_attr_length (insn) == 4 - ? \"b %l0\" : \"l r15,=a(%l0); br r15\"); - }" - [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096)) - (const_int 4) - (const_int 6)))]) + 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: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes +File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble -Constant Attributes -------------------- +Fixed Header Files +================== - A special form of DEFINE_ATTR, where the expression for the default -value is a CONST expression, indicates an attribute that is constant -for a given run of the compiler. Constant attributes may be used to -specify which variety of processor is used. For example, - - (define_attr "cpu" "m88100,m88110,m88000" - (const - (cond [(symbol_ref "TARGET_88100") (const_string "m88100") - (symbol_ref "TARGET_88110") (const_string "m88110")] - (const_string "m88000")))) - - (define_attr "memory" "fast,slow" - (const - (if_then_else (symbol_ref "TARGET_FAST_MEM") - (const_string "fast") - (const_string "slow")))) - - The routine generated for constant attributes has no parameters as -it does not depend on any particular insn. RTL expressions used to -define the value of a constant attribute may use the SYMBOL_REF form, -but may not use either the MATCH_OPERAND form or EQ_ATTR forms -involving insn attributes. + 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: Delay Slots, Next: Function Units, Prev: Constant Attributes, Up: Insn Attributes +File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble -Delay Slot Scheduling ---------------------- +Standard Libraries +================== - The insn attribute mechanism can be used to specify the -requirements for delay slots, if any, on a target machine. An -instruction is said to require a "delay slot" if some instructions -that are physically after the instruction are executed as if they were -located before it. Classic examples are branch and call instructions, -which often execute the following instruction before the branch or -call is performed. - - On some machines, conditional branch instructions can optionally -"annul" instructions in the delay slot. This means that the -instruction will not be executed for certain branch outcomes. Both -instructions that annul if the branch is true and instructions that -annul if the branch is false are supported. - - Delay slot scheduling differs from instruction scheduling in that -determining whether an instruction needs a delay slot is dependent only -on the type of instruction being generated, not on data flow between -the instructions. See the next section for a discussion of -data-dependent instruction scheduling. - - The requirement of an insn needing one or more delay slots is -indicated via the `define_delay' expression. It has the following -form: - - (define_delay TEST - [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 - DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 - ...]) - - TEST is an attribute test that indicates whether this -`define_delay' applies to a particular insn. If so, the number of -required delay slots is determined by the length of the vector -specified as the second argument. An insn placed in delay slot N must -satisfy attribute test DELAY-N. ANNUL-TRUE-N is an attribute test -that specifies which insns may be annulled if the branch is true. -Similarly, ANNUL-FALSE-N specifies which insns in the delay slot may -be annulled if the branch is false. If annulling is not supported for -that delay slot, `(nil)' should be coded. - - For example, in the common case where branch and call insns require -a single delay slot, which may contain any insn other than a branch or -call, the following would be placed in the `md' file: - - (define_delay (eq_attr "type" "branch,call") - [(eq_attr "type" "!branch,call") (nil) (nil)]) - - Multiple `define_delay' expressions may be specified. In this -case, each such expression specifies different delay slot requirements -and there must be no insn for which tests in two `define_delay' -expressions are both true. - - For example, if we have a machine that requires one delay slot for -branches but two for calls, no delay slot can contain a branch or -call insn, and any valid insn in the delay slot for the branch can be -annulled if the branch is true, we might represent this as follows: - - (define_delay (eq_attr "type" "branch") - [(eq_attr "type" "!branch,call") (eq_attr "type" "!branch,call") (nil)]) - - (define_delay (eq_attr "type" "call") - [(eq_attr "type" "!branch,call") (nil) (nil) - (eq_attr "type" "!branch,call") (nil) (nil)]) + 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: Function Units, Prev: Delay Slots, Up: Insn Attributes +File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble + +Disappointments and Misunderstandings +===================================== -Specifying Function Units -------------------------- + These problems are perhaps regrettable, but we don't know any +practical way around them. - On most RISC machines, there are instructions whose results are not -available for a specific number of cycles. Common cases are -instructions that load data from memory. On many machines, a pipeline -stall will result if the data is referenced too soon after the load -instruction. - - In addition, many newer microprocessors have multiple function -units, usually one for integer and one for floating point, and often -will incur pipeline stalls when a result that is needed is not yet -ready. - - The descriptions in this section allow the specification of how much -time must elapse between the execution of an instruction and the time -when its result is used. It also allows specification of when the -execution of an instruction will delay execution of similar -instructions due to function unit conflicts. - - For the purposes of the specifications in this section, a machine is -divided into "function units", each of which execute a specific class -of instructions. Function units that accept one instruction each -cycle and allow a result to be used in the succeeding instruction -(usually via forwarding) need not be specified. Classic RISC -microprocessors will normally have a single function unit, which we can -call `memory'. The newer "superscalar" processors will often have -function units for floating point operations, usually at least a -floating point adder and multiplier. - - Each usage of a function units by a class of insns is specified -with a `define_function_unit' expression, which looks like this: - - (define_function_unit NAME MULTIPLICITY SIMULTANEITY - TEST READY-DELAY BUSY-DELAY - [CONFLICT-LIST]) - - NAME is a string giving the name of the function unit. - - MULTIPLICITY is an integer specifying the number of identical units -in the processor. If more than one unit is specified, they will be -scheduled independently. Only truly independent units should be -counted; a pipelined unit should be specified as a single unit. (The -only common example of a machine that has multiple function units for a -single instruction class that are truly independent and not pipelined -are the two multiply and two increment units of the CDC 6600.) - - SIMULTANEITY specifies the maximum number of insns that can be -executing in each instance of the function unit simultaneously or zero -if the unit is pipelined and has no limit. - - All `define_function_unit' definitions referring to function unit -NAME must have the same name and values for MULTIPLICITY and -SIMULTANEITY. - - TEST is an attribute test that selects the insns we are describing -in this definition. Note that an insn may use more than one function -unit and a function unit may be specified in more than one -`define_function_unit'. - - READY-DELAY is an integer that specifies the number of cycles after -which the result of the instruction can be used without introducing -any stalls. - - BUSY-DELAY is an integer that represents the default cost if an -insn is scheduled for this unit while the unit is active with another -insn. If SIMULTANEITY is zero, this specification is ignored. -Otherwise, a zero value indicates that these insns execute on NAME in -a fully pipelined fashion, even if SIMULTANEITY is non-zero. A -non-zero value indicates that scheduling a new insn on this unit while -another is active will incur a cost. A cost of two indicates a single -cycle delay. For a normal non-pipelined function unit, BUSY-DELAY -will be twice READY-DELAY. - - CONFLICT-LIST is an optional list giving detailed conflict costs -for this unit. If specified, it is a list of condition test -expressions which are applied to insns already executing in NAME. For -each insn that is in the list, BUSY-DELAY will be used for the conflict -cost, while a value of zero will be used for insns not in the list. - - Typical uses of this vector are where a floating point function -unit can pipeline either single- or double-precision operations, but -not both, or where a memory unit can pipeline loads, but not stores, -etc. - - As an example, consider a classic RISC machine where the result of a -load instruction is not available for two cycles (a single "delay" -instruction is required) and where only one load instruction can be -executed simultaneously. This would be specified as: - - (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 4) - - For the case of a floating point function unit that can pipeline -either single or double precision, but not both, the following could -be specified: - - (define_function_unit - "fp" 1 1 (eq_attr "type" "sp_fp") 4 8 (eq_attr "type" "dp_fp")] - (define_function_unit - "fp" 1 1 (eq_attr "type" "dp_fp") 4 8 (eq_attr "type" "sp_fp")] - - *Note:* No code currently exists to avoid function unit conflicts, -only data conflicts. Hence MULTIPLICITY, SIMULTANEITY, BUSY-COST, and -CONFLICT-LIST are currently ignored. When such code is written, it is -possible that the specifications for these values may be changed. It -has recently come to our attention that these specifications may not -allow modeling of some of the newer "superscalar" processors that have -insns using multiple pipelined units. These insns will cause a -potential conflict for the second unit used during their execution and -there is no way of representing that conflict. We welcome any -examples of how function unit conflicts work in such processors and -suggestions for their representation. + * 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: Target Macros, Next: Config, Prev: Machine Desc, Up: Top +File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble -Target Description Macros -************************* +Common Misunderstandings with GNU C++ +===================================== - In addition to the file `MACHINE.md', a machine description -includes a C header file conventionally given the name `MACHINE.h'. -This header file defines numerous macros that convey the information -about the target machine that does not fit into the scheme of the -`.md' file. The file `tm.h' should be a link to `MACHINE.h'. The -header file `config.h' includes `tm.h' and most compiler source files -include `config.h'. + 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: -* Driver:: Controlling how the driver runs the compilation passes. -* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. -* Storage Layout:: Defining sizes and alignments of data. -* Type Layout:: Defining sizes and properties of basic user data types. -* Registers:: Naming and describing the hardware registers. -* Register Classes:: Defining the classes of hardware registers. -* Stack and Calling:: Defining which way the stack grows and by how much. -* Varargs:: Defining the varargs macros. -* Trampolines:: Code set up at run time to enter a nested function. -* Library Calls:: Controlling how library routines are implicitly called. -* Addressing Modes:: Defining addressing modes valid for memory operands. -* Condition Code:: Defining how insns update the condition code. -* Costs:: Defining relative costs of different operations. -* Sections:: Dividing storage into text, data, and other sections. -* PIC:: Macros for position independent code. -* Assembler Format:: Defining how to write insns and pseudo-ops to output. -* Debugging Info:: Defining the format of debugging output. -* Cross-compilation:: Handling floating point for cross-compilers. -* Misc:: Everything else. +* 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 + +Declare *and* Define Static Members +----------------------------------- + + When a class has static data members, it is not enough to *declare* +the static member; you must also *define* it. For example: + + 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. - \ No newline at end of file