--- gcc/gcc.info-10 2018/04/24 17:51:58 1.1.1.2 +++ gcc/gcc.info-10 2018/04/24 18:17:56 1.1.1.7 @@ -1,1156 +1,959 @@ -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 675 Massachusetts Avenue +Cambridge, MA 02139 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 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: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints +File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble + +Problems Compiling Certain Programs +=================================== + + Certain programs have problems compiling. + + * Parse errors may occur compiling X11 on a Decstation running + Ultrix 4.2 because of problems in DEC's versions of the X11 header + files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding + `-I/usr/include/mit' to use the MIT versions of the header files, + using the `-traditional' switch to turn off ANSI C, or fixing the + header files by adding this: + + #ifdef __STDC__ + #define NeedFunctionPrototypes 0 + #endif + + * If you have trouble compiling Perl on a SunOS 4 system, it may be + because Perl specifies `-I/usr/ucbinclude'. This accesses the + unfixed header files. Perl specifies the options + + -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: -Simple Constraints ------------------- + MALLOC=/usr/local/lib/libgmalloc.a - The simplest kind of constraint is a string full of letters, each of -which describes one kind of operand that is permitted. Here are the -letters that are allowed: - -`m' - A memory operand is allowed, with any kind of address that the - machine supports in general. - -`o' - A memory operand is allowed, but only if the address is - "offsettable". This means that adding a small integer (actually, - the width in bytes of the operand, as determined by its machine - mode) may be added to the address and the result is also a valid - memory address. - - For example, an address which is constant is offsettable; so is an - address that is the sum of a register and a constant (as long as a - slightly larger constant is also within the range of - address-offsets supported by the machine); but an autoincrement - or autodecrement address is not offsettable. More complicated - indirect/indexed addresses may or may not be offsettable - depending on the other addressing modes that the machine supports. - - Note that in an output operand which can be matched by another - operand, the constraint letter `o' is valid only when accompanied - by both `<' (if the target machine has predecrement addressing) - and `>' (if the target machine has preincrement addressing). - -`V' - A memory operand that is not offsettable. In other words, - anything that would fit the `m' constraint but not the `o' - constraint. - -`<' - A memory operand with autodecrement addressing (either - predecrement or postdecrement) is allowed. - -`>' - A memory operand with autoincrement addressing (either - preincrement or postincrement) is allowed. - -`r' - A register operand is allowed provided that it is in a general - register. - -`d', `a', `f', ... - Other letters can be defined in machine-dependent fashion to - stand for particular classes of registers. `d', `a' and `f' are - defined on the 68000/68020 to stand for data, address and floating - point registers. - -`i' - An immediate integer operand (one with constant value) is allowed. - This includes symbolic constants whose values will be known only - at assembly time. - -`n' - An immediate integer operand with a known numeric value is - allowed. Many systems cannot support assembly-time constants for - operands less than a word wide. Constraints for these operands - should use `n' rather than `i'. - -`I', `J', `K', ... `P' - Other letters in the range `I' through `P' may be defined in a - machine-dependent fashion to permit immediate integer operands - with explicit integer values in specified ranges. For example, - on the 68000, `I' is defined to stand for the range of values 1 - to 8. This is the range permitted as a shift count in the shift - instructions. - -`E' - An immediate floating operand (expression code `const_double') is - allowed, but only if the target floating point format is the same - as that of the host machine (on which the compiler is running). - -`F' - An immediate floating operand (expression code `const_double') is - allowed. - -`G', `H' - `G' and `H' may be defined in a machine-dependent fashion to - permit immediate floating operands in particular ranges of values. - -`s' - An immediate integer operand whose value is not an explicit - integer is allowed. - - This might appear strange; if an insn allows a constant operand - with a value not known at compile time, it certainly must allow - any known value. So why use `s' instead of `i'? Sometimes it - allows better code to be generated. - - For example, on the 68000 in a fullword instruction it is - possible to use an immediate operand; but if the immediate value - is between -128 and 127, better code results from loading the - value into a register and using the register. This is because - the load into the register can be done with a `moveq' - instruction. We arrange for this to happen by defining the - letter `K' to mean "any integer outside the range -128 to 127", - and then specifying `Ks' in the operand constraints. - -`g' - Any register, memory or immediate integer operand is allowed, - except for registers that are not general registers. - -`X' - Any operand whatsoever is allowed, even if it does not satisfy - `general_operand'. This is normally used in the constraint of a - `match_scratch' when certain alternatives will not actually - require a scratch register. - -`0', `1', `2', ... `9' - An operand that matches the specified operand number is allowed. - If a digit is used together with letters within the same - alternative, the digit should come last. - - This is called a "matching constraint" and what it really means is - that the assembler has only a single operand that fills two roles - considered separate in the RTL insn. For example, an add insn - has two input operands and one output operand in the RTL, but on - most machines an add instruction really has only two operands, - one of them an input-output operand. - - Matching constraints work only in circumstances like that add - insn. More precisely, the two operands that match must include - one input-only operand and one output-only operand. Moreover, - the digit must be a smaller number than the number of the operand - that uses it in the constraint. - - For operands to match in a particular case usually means that they - are identical-looking RTL expressions. But in a few special cases - specific kinds of dissimilarity are allowed. For example, `*x' - as an input operand will match `*x++' as an output operand. For - proper results in such cases, the output template should always - use the output-operand's number when printing the operand. - -`p' - An operand that is a valid memory address is allowed. This is - for "load address" and "push address" instructions. - - `p' in the constraint must be accompanied by `address_operand' as - the predicate in the `match_operand'. This predicate interprets - the mode specified in the `match_operand' as the mode of the - memory reference for which the address would be valid. - -`Q', `R', `S', ... `U' - Letters in the range `Q' through `U' may be defined in a - machine-dependent fashion to stand for arbitrary operand types. - The machine description macro `EXTRA_CONSTRAINT' is passed the - operand as its first argument and the constraint letter as its - second operand. - - A typical use for this would be to distinguish certain types of - memory references that affect other insn operands. - - Do not define these constraint letters to accept register - references (`reg'); the reload pass does not expect this and - would not handle it properly. - - In order to have valid assembler code, each operand must satisfy -its constraint. But a failure to do so does not prevent the pattern -from applying to an insn. Instead, it directs the compiler to modify -the code so that the constraint will be satisfied. Usually this is -done by copying an operand into a register. - - Contrast, therefore, the two instruction patterns that follow: - - (define_insn "" - [(set (match_operand:SI 0 "general_operand" "r") - (plus:SI (match_dup 0) - (match_operand:SI 1 "general_operand" "r")))] - "" - "...") - -which has two operands, one of which must appear in two places, and - - (define_insn "" - [(set (match_operand:SI 0 "general_operand" "r") - (plus:SI (match_operand:SI 1 "general_operand" "0") - (match_operand:SI 2 "general_operand" "r")))] - "" - "...") - -which has three operands, two of which are required by a constraint to -be identical. If we are considering an insn of the form - - (insn N PREV NEXT - (set (reg:SI 3) - (plus:SI (reg:SI 6) (reg:SI 109))) - ...) - -the first pattern would not apply at all, because this insn does not -contain two identical subexpressions in the right place. The pattern -would say, "That does not look like an add instruction; try other -patterns." The second pattern would say, "Yes, that's an add -instruction, but there is something wrong with it." It would direct -the reload pass of the compiler to generate additional insns to make -the constraint true. The results might look like this: - - (insn N2 PREV N - (set (reg:SI 3) (reg:SI 6)) - ...) - - (insn N N2 NEXT - (set (reg:SI 3) - (plus:SI (reg:SI 3) (reg:SI 109))) - ...) - - It is up to you to make sure that each operand, in each pattern, has -constraints that can handle any RTL expression that could be present -for that operand. (When multiple alternatives are in use, each -pattern must, for each possible combination of operand expressions, -have at least one alternative which can handle that combination of -operands.) The constraints don't need to *allow* any possible -operand--when this is the case, they do not constrain--but they must -at least point the way to reloading any possible operand so that it -will fit. - - * If the constraint accepts whatever operands the predicate permits, - there is no problem: reloading is never necessary for this - operand. - - For example, an operand whose constraints permit everything except - registers is safe provided its predicate rejects registers. - - An operand whose predicate accepts only constant values is safe - provided its constraints include the letter `i'. If any possible - constant value is accepted, then nothing less than `i' will do; - if the predicate is more selective, then the constraints may also - be more selective. - - * Any operand expression can be reloaded by copying it into a - register. So if an operand's constraints allow some kind of - register, it is certain to be safe. It need not permit all - classes of registers; the compiler knows how to copy a register - into another register of the proper class in order to make an - instruction valid. - - * A nonoffsettable memory reference can be reloaded by copying the - address into a register. So if the constraint uses the letter - `o', all memory references are taken care of. - - * A constant operand can be reloaded by allocating space in memory - to hold it as preinitialized data. Then the memory reference can - be used in place of the constant. So if the constraint uses the - letters `o' or `m', constant operands are not a problem. - - * If the constraint permits a constant and a pseudo register used - in an insn was not allocated to a hard register and is equivalent - to a constant, the register will be replaced with the constant. - If the predicate does not permit a constant and the insn is - re-recognized for some reason, the compiler will crash. Thus the - predicate must always recognize any objects allowed by the - constraint. - - If the operand's predicate can recognize registers, but the -constraint does not permit them, it can make the compiler crash. When -this operand happens to be a register, the reload pass will be -stymied, because it does not know how to copy a register temporarily -into memory. + 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: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints +File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble -Multiple Alternative Constraints --------------------------------- +Incompatibilities of GNU CC +=========================== - Sometimes a single instruction has multiple alternative sets of -possible operands. For example, on the 68000, a logical-or -instruction can combine register or an immediate value into memory, or -it can combine any kind of operand into a register; but it cannot -combine one memory location into another. - - These constraints are represented as multiple alternatives. An -alternative can be described by a series of letters for each operand. -The overall constraint for an operand is made from the letters for -this operand from the first alternative, a comma, the letters for this -operand from the second alternative, a comma, and so on until the last -alternative. Here is how it is done for fullword logical-or on the -68000: - - (define_insn "iorsi3" - [(set (match_operand:SI 0 "general_operand" "=m,d") - (ior:SI (match_operand:SI 1 "general_operand" "%0,0") - (match_operand:SI 2 "general_operand" "dKs,dmKs")))] - ...) - - The first alternative has `m' (memory) for operand 0, `0' for -operand 1 (meaning it must match operand 0), and `dKs' for operand 2. -The second alternative has `d' (data register) for operand 0, `0' for -operand 1, and `dmKs' for operand 2. The `=' and `%' in the -constraints apply to all the alternatives; their meaning is explained -in the next section (*note Class Preferences::.). - - If all the operands fit any one alternative, the instruction is -valid. Otherwise, for each alternative, the compiler counts how many -instructions must be added to copy the operands so that that -alternative applies. The alternative requiring the least copying is -chosen. If two alternatives need the same amount of copying, the one -that comes first is chosen. These choices can be altered with the `?' -and `!' characters: - -`?' - Disparage slightly the alternative that the `?' appears in, as a - choice when no alternative applies exactly. The compiler regards - this alternative as one unit more costly for each `?' that appears + 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. -`!' - Disparage severely the alternative that the `!' appears in. This - alternative can still be used if it fits without reloading, but - if reloading is needed, some other alternative will be used. - - When an insn pattern has multiple alternatives in its constraints, -often the appearance of the assembler code is determined mostly by -which alternative was matched. When this is so, the C code for -writing the assembler code can use the variable `which_alternative', -which is the ordinal number of the alternative that was actually -satisfied (0 for the first, 1 for the second alternative, etc.). -*Note Output Statement::. + 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 preprocessor 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 + preprocessor 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: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints +File: gcc.info, Node: Fixed Headers, Next: Disappointments, Prev: Incompatibilities, Up: Trouble -Register Class Preferences --------------------------- +Fixed Header Files +================== - The operand constraints have another function: they enable the -compiler to decide which kind of hardware register a pseudo register -is best allocated to. The compiler examines the constraints that -apply to the insns that use the pseudo register, looking for the -machine-dependent letters such as `d' and `a' that specify classes of -registers. The pseudo register is put in whichever class gets the -most "votes". The constraint letters `g' and `r' also vote: they vote -in favor of a general register. The machine description says which -registers are considered general. - - Of course, on some machines all registers are equivalent, and no -register classes are defined. Then none of this complexity is -relevant. + 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: Modifiers, Next: No Constraints, Prev: Class Preferences, Up: Constraints +File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Fixed Headers, Up: Trouble -Constraint Modifier Characters ------------------------------- +Disappointments and Misunderstandings +===================================== -`=' - Means that this operand is write-only for this instruction: the - previous value is discarded and replaced by output data. - -`+' - Means that this operand is both read and written by the - instruction. - - When the compiler fixes up the operands to satisfy the - constraints, it needs to know which operands are inputs to the - instruction and which are outputs from it. `=' identifies an - output; `+' identifies an operand that is both input and output; - all other operands are assumed to be input only. - -`&' - Means (in a particular alternative) that this operand is written - before the instruction is finished using the input operands. - Therefore, this operand may not lie in a register that is used as - an input operand or as part of any memory address. - - `&' applies only to the alternative in which it is written. In - constraints with multiple alternatives, sometimes one alternative - requires `&' while others do not. See, for example, the `movdf' - insn of the 68000. - - `&' does not obviate the need to write `='. - -`%' - Declares the instruction to be commutative for this operand and - the following operand. This means that the compiler may - interchange the two operands if that is the cheapest way to make - all operands fit the constraints. This is often used in patterns - for addition instructions that really have only two operands: the - result must go in one of the arguments. Here for example, is how - the 68000 halfword-add instruction is defined: - - (define_insn "addhi3" - [(set (match_operand:HI 0 "general_operand" "=m,r") - (plus:HI (match_operand:HI 1 "general_operand" "%0,0") - (match_operand:HI 2 "general_operand" "di,g")))] - ...) - -`#' - Says that all following characters, up to the next comma, are to - be ignored as a constraint. They are significant only for - choosing register preferences. - -`*' - Says that the following character should be ignored when choosing - register preferences. `*' has no effect on the meaning of the - constraint as a constraint, and no effect on reloading. - - Here is an example: the 68000 has an instruction to sign-extend a - halfword in a data register, and can also sign-extend a value by - copying it into an address register. While either kind of - register is acceptable, the constraints on an address-register - destination are less strict, so it is best if register allocation - makes an address register its goal. Therefore, `*' is used so - that the `d' constraint letter (for data register) is ignored - when computing register preferences. - - (define_insn "extendhisi2" - [(set (match_operand:SI 0 "general_operand" "=*d,a") - (sign_extend:SI - (match_operand:HI 1 "general_operand" "0,g")))] - ...) + These problems are perhaps regrettable, but we don't know any +practical way around them. + + * 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: No Constraints, Prev: Modifiers, Up: Constraints +File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble + +Common Misunderstandings with GNU C++ +===================================== + + C++ is a complex language and an evolving one, and its standard +definition (the ANSI C++ draft standard) is also evolving. As a result, +your C++ compiler may occasionally surprise you, even when its behavior +is correct. This section discusses some areas that frequently give +rise to questions of this sort. -Not Using Constraints ---------------------- +* Menu: - Some machines are so clean that operand constraints are not -required. For example, on the Vax, an operand valid in one context is -valid in any other context. On such a machine, every operand -constraint would be `g', excepting only operands of "load address" -instructions which are written as if they referred to a memory -location's contents but actual refer to its address. They would have -constraint `p'. - - For such machines, instead of writing `g' and `p' for all the -constraints, you can choose to write a description with empty -constraints. Then you write `""' for the constraint in every -`match_operand'. Address operands are identified by writing an -`address' expression around the `match_operand', not by their -constraints. - - When the machine description has just empty constraints, certain -parts of compilation are skipped, making the compiler faster. However, -few machines actually do not need constraints; all machine descriptions -now in existence use constraints. +* Static Definitions:: Static member declarations are not definitions +* Temporaries:: Temporaries may vanish before you expect  -File: gcc.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc +File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings -Standard Names for Patterns Used in Generation -============================================== +Declare *and* Define Static Members +----------------------------------- - Here is a table of the instruction names that are meaningful in the -RTL generation pass of the compiler. Giving one of these names to an -instruction pattern tells the RTL generation pass that it can use the -pattern in to accomplish a certain task. - -`movM' - Here M stands for a two-letter machine mode name, in lower case. - This instruction pattern moves data with that machine mode from - operand 1 to operand 0. For example, `movsi' moves full-word - data. - - If operand 0 is a `subreg' with mode M of a register whose own - mode is wider than M, the effect of this instruction is to store - the specified value in the part of the register that corresponds - to mode M. The effect on the rest of the register is undefined. - - This class of patterns is special in several ways. First of all, - each of these names *must* be defined, because there is no other - way to copy a datum from one place to another. - - Second, these patterns are not used solely in the RTL generation - pass. Even the reload pass can generate move insns to copy - values from stack slots into temporary registers. When it does - so, one of the operands is a hard register and the other is an - operand that can need to be reloaded into a register. - - Therefore, when given such a pair of operands, the pattern must - generate RTL which needs no reloading and needs no temporary - registers--no registers other than the operands. For example, if - you support the pattern with a `define_expand', then in such a - case the `define_expand' mustn't call `force_reg' or any other - such function which might generate new pseudo registers. - - This requirement exists even for subword modes on a RISC machine - where fetching those modes from memory normally requires several - insns and some temporary registers. Look in `spur.md' to see how - the requirement can be satisfied. - - During reload a memory reference with an invalid address may be - passed as an operand. Such an address will be replaced with a - valid address later in the reload pass. In this case, nothing - may be done with the address except to use it as it stands. If - it is copied, it will not be replaced with a valid address. No - attempt should be made to make such an address into a valid - address and no routine (such as `change_address') that will do so - may be called. Note that `general_operand' will fail when - applied to such an address. - - The global variable `reload_in_progress' (which must be explicitly - declared if required) can be used to determine whether such - special handling is required. - - The variety of operands that have reloads depends on the rest of - the machine description, but typically on a RISC machine these - can only be pseudo registers that did not get hard registers, - while on other machines explicit memory references will get - optional reloads. - - If a scratch register is required to move an object to or from - memory, it can be allocated using `gen_reg_rtx' prior to reload. - But this is impossible during and after reload. If there are - cases needing scratch registers after reload, you must define - `SECONDARY_INPUT_RELOAD_CLASS' and/or - `SECONDARY_OUTPUT_RELOAD_CLASS' to detect them, and provide - patterns `reload_inM' or `reload_outM' to handle them. *Note - Register Classes::. - - The constraints on a `moveM' must permit moving any hard register - to any other hard register provided that `HARD_REGNO_MODE_OK' - permits mode M in both registers and `REGISTER_MOVE_COST' applied - to their classes returns a value of 2. - - It is obligatory to support floating point `moveM' instructions - into and out of any registers that can hold fixed point values, - because unions and structures (which have modes `SImode' or - `DImode') can be in those registers and they may have floating - point members. - - There may also be a need to support fixed point `moveM' - instructions in and out of floating point registers. - Unfortunately, I have forgotten why this was so, and I don't know - whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed - point values in floating point registers, then the constraints of - the fixed point `moveM' instructions must be designed to avoid - ever trying to reload into a floating point register. - -`reload_inM' -`reload_outM' - Like `movM', but used when a scratch register is required to move - between operand 0 and operand 1. Operand 2 describes the scratch - register. See the discussion of the `SECONDARY_RELOAD_CLASS' - macro in *note Register Classes::.. - -`movstrictM' - Like `movM' except that if operand 0 is a `subreg' with mode M of - a register whose natural mode is wider, the `movstrictM' - instruction is guaranteed not to alter any of the register except - the part which belongs to mode M. - -`addM3' - Add operand 2 and operand 1, storing the result in operand 0. - All operands must have mode M. This can be used even on - two-address machines, by means of constraints requiring operands - 1 and 0 to be the same location. - -`subM3', `mulM3' -`divM3', `udivM3', `modM3', `umodM3' -`sminM3', `smaxM3', `uminM3', `umaxM3' -`andM3', `iorM3', `xorM3' - Similar, for other arithmetic operations. - -`mulhisi3' - Multiply operands 1 and 2, which have mode `HImode', and store a - `SImode' product in operand 0. - -`mulqihi3', `mulsidi3' - Similar widening-multiplication instructions of other widths. - -`umulqihi3', `umulhisi3', `umulsidi3' - Similar widening-multiplication instructions that do unsigned - multiplication. - -`divmodM4' - Signed division that produces both a quotient and a remainder. - Operand 1 is divided by operand 2 to produce a quotient stored in - operand 0 and a remainder stored in operand 3. - - For machines with an instruction that produces both a quotient - and a remainder, provide a pattern for `divmodM4' but do not - provide patterns for `divM3' and `modM3'. This allows - optimization in the relatively common case when both the quotient - and remainder are computed. - - If an instruction that just produces a quotient or just a - remainder exists and is more efficient than the instruction that - produces both, write the output routine of `divmodM4' to call - `find_reg_note' and look for a `REG_UNUSED' note on the quotient - or remainder and generate the appropriate instruction. - -`udivmodM4' - Similar, but does unsigned division. - -`ashlM3' - Arithmetic-shift operand 1 left by a number of bits specified by - operand 2, and store the result in operand 0. Operand 2 has mode - `SImode', not mode M. - -`ashrM3', `lshlM3', `lshrM3', `rotlM3', `rotrM3' - Other shift and rotate instructions. - - Logical and arithmetic left shift are the same. Machines that do - not allow negative shift counts often have only one instruction - for shifting left. On such machines, you should define a pattern - named `ashlM3' and leave `lshlM3' undefined. - -`negM2' - Negate operand 1 and store the result in operand 0. - -`absM2' - Store the absolute value of operand 1 into operand 0. - -`sqrtM2' - Store the square root of operand 1 into operand 0. - -`ffsM2' - Store into operand 0 one plus the index of the least significant - 1-bit of operand 1. If operand 1 is zero, store zero. M is the - mode of operand 0; operand 1's mode is specified by the - instruction pattern, and the compiler will convert the operand to - that mode before generating the instruction. - -`one_cmplM2' - Store the bitwise-complement of operand 1 into operand 0. - -`cmpM' - Compare operand 0 and operand 1, and set the condition codes. - The RTL pattern should look like this: - - (set (cc0) (compare (match_operand:M 0 ...) - (match_operand:M 1 ...))) - -`tstM' - Compare operand 0 against zero, and set the condition codes. The - RTL pattern should look like this: - - (set (cc0) (match_operand:M 0 ...)) - - `tstM' patterns should not be defined for machines that do not - use `(cc0)'. Doing so would confuse the optimizer since it would - no longer be clear which `set' operations were comparisons. The - `cmpM' patterns should be used instead. - -`movstrM' - Block move instruction. The addresses of the destination and - source strings are the first two operands, and both are in mode - `Pmode'. The number of bytes to move is the third operand, in - mode M. - - The fourth operand is the known shared alignment of the source and - destination, in the form of a `const_int' rtx. Thus, if the - compiler knows that both source and destination are word-aligned, - it may provide the value 4 for this operand. - - These patterns need not give special consideration to the - possibility that the source and destination strings might overlap. - -`cmpstrM' - Block compare instruction, with five operands. Operand 0 is the - output; it has mode M. The remaining four operands are like the - operands of `movstrM'. The two memory blocks specified are - compared byte by byte in lexicographic order. The effect of the - instruction is to store a value in operand 0 whose sign indicates - the result of the comparison. - -`floatMN2' - Convert signed integer operand 1 (valid for fixed point mode M) to - floating point mode N and store in operand 0 (which has mode N). - -`floatunsMN2' - Convert unsigned integer operand 1 (valid for fixed point mode M) - to floating point mode N and store in operand 0 (which has mode - N). - -`fixMN2' - Convert operand 1 (valid for floating point mode M) to fixed - point mode N as a signed number and store in operand 0 (which has - mode N). This instruction's result is defined only when the - value of operand 1 is an integer. - -`fixunsMN2' - Convert operand 1 (valid for floating point mode M) to fixed - point mode N as an unsigned number and store in operand 0 (which - has mode N). This instruction's result is defined only when the - value of operand 1 is an integer. - -`ftruncM2' - Convert operand 1 (valid for floating point mode M) to an integer - value, still represented in floating point mode M, and store it - in operand 0 (valid for floating point mode M). - -`fix_truncMN2' - Like `fixMN2' but works for any floating point value of mode M by - converting the value to an integer. - -`fixuns_truncMN2' - Like `fixunsMN2' but works for any floating point value of mode M - by converting the value to an integer. - -`truncMN' - Truncate operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`extendMN' - Sign-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point or - both floating point. - -`zero_extendMN' - Zero-extend operand 1 (valid for mode M) to mode N and store in - operand 0 (which has mode N). Both modes must be fixed point. - -`extv' - Extract a bit field from operand 1 (a register or memory - operand), where operand 2 specifies the width in bits and operand - 3 the starting bit, and store it in operand 0. Operand 0 must - have mode `word_mode'. Operand 1 may have mode `byte_mode' or - `word_mode'; often `word_mode' is allowed only for registers. - Operands 2 and 3 must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 2 and 3. - - The bit-field value is sign-extended to a full word integer - before it is stored in operand 0. - -`extzv' - Like `extv' except that the bit-field value is zero-extended. - -`insv' - Store operand 3 (which must be valid for `word_mode') into a bit - field in operand 0, where operand 1 specifies the width in bits - and operand 2 the starting bit. Operand 0 may have mode - `byte_mode' or `word_mode'; often `word_mode' is allowed only for - registers. Operands 1 and 2 must be valid for `word_mode'. - - The RTL generation pass generates this instruction only with - constants for operands 1 and 2. - -`sCOND' - Store zero or nonzero in the operand according to the condition - codes. Value stored is nonzero iff the condition COND is true. - COND is the name of a comparison operation expression code, such - as `eq', `lt' or `leu'. - - You specify the mode that the operand must have when you write the - `match_operand' expression. The compiler automatically sees - which mode you have used and supplies an operand of that mode. - - The value stored for a true condition must have 1 as its low bit, - or else must be negative. Otherwise the instruction is not - suitable and you should omit it from the machine description. - You describe to the compiler exactly which value is stored by - defining the macro `STORE_FLAG_VALUE' (*note Misc::.). If a - description cannot be found that can be used for all the `sCOND' - patterns, you should omit those operations from the machine - description. - - These operations may fail, but should do so only in relatively - uncommon cases; if they would fail for common cases involving - integer comparisons, it is best to omit these patterns. - - If these operations are omitted, the compiler will usually - generate code that copies the constant one to the target and - branches around an assignment of zero to the target. If this - code is more efficient than the potential instructions used for - the `sCOND' pattern followed by those required to convert the - result into a 1 or a zero in `SImode', you should omit the - `sCOND' operations from the machine description. - -`bCOND' - Conditional branch instruction. Operand 0 is a `label_ref' that - refers to the label to jump to. Jump if the condition codes meet - condition COND. - - Some machines do not follow the model assumed here where a - comparison instruction is followed by a conditional branch - instruction. In that case, the `cmpM' (and `tstM') patterns - should simply store the operands away and generate all the - required insns in a `define_expand' (*note Expander - Definitions::.) for the conditional branch operations. All calls - to expand `vCOND' patterns are immediately preceded by calls to - expand either a `cmpM' pattern or a `tstM' pattern. - - Machines that use a pseudo register for the condition code value, - or where the mode used for the comparison depends on the - condition being tested, should also use the above mechanism. - *Note Jump Patterns:: - - The above discussion also applies to `sCOND' patterns. - -`call' - Subroutine call instruction returning no value. Operand 0 is the - function to call; operand 1 is the number of bytes of arguments - pushed (in mode `SImode', except it is normally a `const_int'); - operand 2 is the number of registers used as operands. - - On most machines, operand 2 is not actually stored into the RTL - pattern. It is supplied for the sake of some RISC machines which - need to put this information into the assembler code; they can - put it in the RTL instead of operand 1. - - Operand 0 should be a `mem' RTX whose address is the address of - the function. Note, however, that this address can be a - `symbol_ref' expression even if it would not be a legitimate - memory address on the target machine. If it is also not a valid - argument for a call instruction, the pattern for this operation - should be a `define_expand' (*note Expander Definitions::.) that - places the address into a register and uses that register in the - call instruction. - -`call_value' - Subroutine call instruction returning a value. Operand 0 is the - hard register in which the value is returned. There are three - more operands, the same as the three operands of the `call' - instruction (but with numbers increased by one). - - Subroutines that return `BLKmode' objects use the `call' insn. - -`call_pop', `call_value_pop' - Similar to `call' and `call_value', except used if defined and if - `RETURN_POPS_ARGS' is non-zero. They should emit a `parallel' - that contains both the function call and a `set' to indicate the - adjustment made to the frame pointer. - - For machines where `RETURN_POPS_ARGS' can be non-zero, the use of - these patterns increases the number of functions for which the - frame pointer can be eliminated, if desired. - -`return' - Subroutine return instruction. This instruction pattern name - should be defined only if a single instruction can do all the - work of returning from a function. - - Like the `movM' patterns, this pattern is also used after the RTL - generation phase. In this case it is to support machines where - multiple instructions are usually needed to return from a - function, but some class of functions only requires one - instruction to implement a return. Normally, the applicable - functions are those which do not need to save any registers or - allocate stack space. - - For such machines, the condition specified in this pattern should - only be true when `reload_completed' is non-zero and the - function's epilogue would only be a single instruction. For - machines with register windows, the routine `leaf_function_p' may - be used to determine if a register window push is required. - - Machines that have conditional return instructions should define - patterns such as - - (define_insn "" - [(set (pc) - (if_then_else (match_operator 0 "comparison_operator" - [(cc0) (const_int 0)]) - (return) - (pc)))] - "CONDITION" - "...") - - where CONDITION would normally be the same condition specified on - the named `return' pattern. - -`nop' - No-op instruction. This instruction pattern name should always - be defined to output a no-op in assembler code. `(const_int 0)' - will do as an RTL pattern. - -`indirect_jump' - An instruction to jump to an address which is operand zero. This - pattern name is mandatory on all machines. - -`casesi' - Instruction to jump through a dispatch table, including bounds - checking. This instruction takes five operands: - - 1. The index to dispatch on, which has mode `SImode'. - - 2. The lower bound for indices in the table, an integer - constant. - - 3. The total range of indices in the table--the largest index - minus the smallest one (both inclusive). - - 4. A label that precedes the table itself. - - 5. A label to jump to if the index has a value outside the - bounds. (If the machine-description macro - `CASE_DROPS_THROUGH' is defined, then an out-of-bounds index - drops through to the code following the jump table instead - of jumping to this label. In that case, this label is not - actually used by the `casesi' instruction, but it is always - provided as an operand.) - - The table is a `addr_vec' or `addr_diff_vec' inside of a - `jump_insn'. The number of elements in the table is one plus the - difference between the upper bound and the lower bound. - -`tablejump' - Instruction to jump to a variable address. This is a low-level - capability which can be used to implement a dispatch table when - there is no `casesi' pattern. - - This pattern requires two operands: the address or offset, and a - label which should immediately precede the jump table. If the - macro `CASE_VECTOR_PC_RELATIVE' is defined then the first operand - is an offset which counts from the address of the table; - otherwise, it is an absolute address to jump to. - - The `tablejump' insn is always the last insn before the jump - table it uses. Its assembler code normally has no need to use the - second operand, but you should incorporate it in the RTL pattern - so that the jump optimizer will not delete the table as - unreachable code. + 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.  -File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc +File: gcc.info, Node: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings + +Temporaries May Vanish Before You Expect +---------------------------------------- -When the Order of Patterns Matters -================================== + It is dangerous to use pointers or references to *portions* of a +temporary object. The compiler may very well delete the object before +you expect it to, leaving a pointer to garbage. The most common place +where this problem crops up is in classes like the libg++ `String' +class, that define a conversion function to type `char *' or `const +char *'. However, any class that returns a pointer to some internal +structure is potentially subject to this problem. + + For example, a program may use a function `strfunc' that returns +`String' objects, and another function `charfunc' that operates on +pointers to `char': + + String strfunc (); + void charfunc (const char *); + +In this situation, it may seem natural to write +`charfunc (strfunc ());' based on the knowledge that class `String' has +an explicit conversion to `char' pointers. However, what really +happens is akin to `charfunc (strfunc ().convert ());', where the +`convert' method is a function to do the same data conversion normally +performed by a cast. Since the last use of the temporary `String' +object is the call to the conversion function, the compiler may delete +that object before actually calling `charfunc'. The compiler has no +way of knowing that deleting the `String' object will invalidate the +pointer. The pointer then points to garbage, so that by the time +`charfunc' is called, it gets an invalid argument. + + Code like this may run successfully under some other compilers, +especially those that delete temporaries relatively late. However, the +GNU C++ behavior is also standard-conformant, so if your program depends +on late destruction of temporaries it is not portable. + + If you think this is surprising, you should be aware that the ANSI +C++ committee continues to debate the lifetime-of-temporaries problem. + + For now, at least, the safe way to write such code is to give the +temporary a name, which forces it to remain until the end of the scope +of the name. For example: - Sometimes an insn can match more than one instruction pattern. -Then the pattern that appears first in the machine description is the -one used. Therefore, more specific patterns (patterns that will match -fewer things) and faster instructions (those that will produce better -code when they do match) should usually go first in the description. - - In some cases the effect of ordering the patterns can be used to -hide a pattern when it is not valid. For example, the 68000 has an -instruction for converting a fullword to floating point and another -for converting a byte to floating point. An instruction converting an -integer to floating point could match either one. We put the pattern -to convert the fullword first to make sure that one will be used -rather than the other. (Otherwise a large integer might be generated -as a single-byte immediate quantity, which would not work.) Instead of -using this pattern ordering it would be possible to make the pattern -for convert-a-byte smart enough to deal properly with any constant -value. + String& tmp = strfunc (); + charfunc (tmp);  -File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc +File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble -Interdependence of Patterns +Caveats of using `protoize' =========================== - Every machine description must have a named pattern for each of the -conditional branch names `bCOND'. The recognition template must -always have the form - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (label_ref (match_operand 0 "" "")) - (pc))) - -In addition, every machine description must have an anonymous pattern -for each of the possible reverse-conditional branches. Their templates -look like - - (set (pc) - (if_then_else (COND (cc0) (const_int 0)) - (pc) - (label_ref (match_operand 0 "" "")))) - -They are necessary because jump optimization can turn -direct-conditional branches into reverse-conditional branches. - - It is often convenient to use the `match_operator' construct to -reduce the number of patterns that must be specified for branches. For -example, - - (define_insn "" - [(set (pc) - (if_then_else (match_operator 0 "comparison_operator" - [(cc0) (const_int 0)]) - (pc) - (label_ref (match_operand 1 "" ""))))] - "CONDITION" - "...") - - In some cases machines support instructions identical except for the -machine mode of one or more operands. For example, there may be -"sign-extend halfword" and "sign-extend byte" instructions whose -patterns are - - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:HI 1 ...))) - - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:QI 1 ...))) - -Constant integers do not specify a machine mode, so an instruction to -extend a constant value could match either pattern. The pattern it -actually will match is the one that appears first in the file. For -correct results, this must be the one for the widest possible mode -(`HImode', here). If the pattern matches the `QImode' instruction, -the results will be incorrect if the constant value does not actually -fit that mode. - - Such instructions to extend constants are rarely generated because -they are optimized away, but they do occasionally happen in -nonoptimized compilations. - - If a constraint in a pattern allows a constant, the reload pass may -replace a register with a constant permitted by the constraint in some -cases. Similarly for memory references. You must ensure that the -predicate permits all objects allowed by the constraints to prevent the -compiler from crashing. - - Because of this substitution, you should not provide separate -patterns for increment and decrement instructions. Instead, they -should be generated from the same pattern that supports -register-register add insns by examining the operands and generating -the appropriate machine instruction. + The conversion programs `protoize' and `unprotoize' can sometimes +change a source file in a way that won't work unless you rearrange it. + + * `protoize' can insert references to a type name or type tag before + the definition, or in a file where they are not defined. + + If this happens, compiler error messages should show you where the + new references are, so fixing the file by hand is straightforward. + + * There are some C constructs which `protoize' cannot figure out. + For example, it can't determine argument types for declaring a + pointer-to-function variable; this you must do by hand. `protoize' + inserts a comment containing `???' each time it finds such a + variable; so you can find all such variables by searching for this + string. ANSI C does not require declaring the argument types of + pointer-to-function types. + + * Using `unprotoize' can easily introduce bugs. If the program + relied on prototypes to bring about conversion of arguments, these + conversions will not take place in the program without prototypes. + One case in which you can be sure `unprotoize' is safe is when you + are removing prototypes that were made with `protoize'; if the + program worked before without any prototypes, it will work again + without them. + + You can find all the places where this problem might occur by + compiling the program with the `-Wconversion' option. It prints a + warning whenever an argument is converted. + + * Both conversion programs can be confused if there are macro calls + in and around the text to be converted. In other words, the + standard syntax for a declaration or definition must not result + from expanding a macro. This problem is inherent in the design of + C and cannot be fixed. If only a few functions have confusing + macro calls, you can easily convert them manually. + + * `protoize' cannot get the argument types for a function whose + definition was not actually compiled due to preprocessor + conditionals. When this happens, `protoize' changes nothing in + regard to such a function. `protoize' tries to detect such + instances and warn about them. + + You can generally work around this problem by using `protoize' step + by step, each time specifying a different set of `-D' options for + compilation, until all of the functions have been converted. + There is no automatic way to verify that you have got them all, + however. + + * Confusion may result if there is an occasion to convert a function + declaration or definition in a region of source code where there + is more than one formal parameter list present. Thus, attempts to + convert code containing multiple (conditionally compiled) versions + of a single function header (in the same vicinity) may not produce + the desired (or expected) results. + + If you plan on converting source files which contain such code, it + is recommended that you first make sure that each conditionally + compiled region of source code which contains an alternative + function header also contains at least one additional follower + token (past the final right parenthesis of the function header). + This should circumvent the problem. + + * `unprotoize' can become confused when trying to convert a function + definition or declaration which contains a declaration for a + pointer-to-function formal argument which has the same name as the + function being defined or declared. We recommand you avoid such + choices of formal parameter names. + + * You might also want to correct some of the indentation by hand and + break long lines. (The conversion programs don't write lines + longer than eighty characters in any case.) + + +File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Protoize Caveats, Up: Trouble + +Certain Changes We Don't Want to Make +===================================== + + This section lists changes that people frequently request, but which +we do not make because we think GNU CC is better without them. + + * Checking the number and type of arguments to a function which has + an old-fashioned definition and no prototype. + + Such a feature would work only occasionally--only for calls that + appear in the same file as the called function, following the + definition. The only way to check all calls reliably is to add a + prototype for the function. But adding a prototype eliminates the + motivation for this feature. So the feature is not worthwhile. + + * Warning about using an expression whose type is signed as a shift + count. + + Shift count operands are probably signed more often than unsigned. + Warning about this would cause far more annoyance than good. + + * Warning about assigning a signed value to an unsigned variable. + + Such assignments must be very common; warning about them would + cause more annoyance than good. + + * Warning about unreachable code. + + It's very common to have unreachable code in machine-generated + programs. For example, this happens normally in some files of GNU + C itself. + + * Warning when a non-void function value is ignored. + + Coming as I do from a Lisp background, I balk at the idea that + there is something dangerous about discarding a value. There are + functions that return values which some callers may find useful; + it makes no sense to clutter the program with a cast to `void' + whenever the value isn't useful. + + * Assuming (for optimization) that the address of an external symbol + is never zero. + + This assumption is false on certain systems when `#pragma weak' is + used. + + * Making `-fshort-enums' the default. + + This would cause storage layout to be incompatible with most other + C compilers. And it doesn't seem very important, given that you + can get the same result in other ways. The case where it matters + most is when the enumeration-valued object is inside a structure, + and in that case you can specify a field width explicitly. + + * Making bitfields unsigned by default on particular machines where + "the ABI standard" says to do so. + + The ANSI C standard leaves it up to the implementation whether a + bitfield declared plain `int' is signed or not. This in effect + creates two alternative dialects of C. + + The GNU C compiler supports both dialects; you can specify the + signed dialect with `-fsigned-bitfields' and the unsigned dialect + with `-funsigned-bitfields'. However, this leaves open the + question of which dialect to use by default. + + Currently, the preferred dialect makes plain bitfields signed, + because this is simplest. Since `int' is the same as `signed int' + in every other context, it is cleanest for them to be the same in + bitfields as well. + + Some computer manufacturers have published Application Binary + Interface standards which specify that plain bitfields should be + unsigned. It is a mistake, however, to say anything about this + issue in an ABI. This is because the handling of plain bitfields + distinguishes two dialects of C. Both dialects are meaningful on + every type of machine. Whether a particular object file was + compiled using signed bitfields or unsigned is of no concern to + other object files, even if they access the same bitfields in the + same data structures. + + A given program is written in one or the other of these two + dialects. The program stands a chance to work on most any machine + if it is compiled with the proper dialect. It is unlikely to work + at all if compiled with the wrong dialect. + + Many users appreciate the GNU C compiler because it provides an + environment that is uniform across machines. These users would be + inconvenienced if the compiler treated plain bitfields differently + on certain machines. + + Occasionally users write programs intended only for a particular + machine type. On these occasions, the users would benefit if the + GNU C compiler were to support by default the same dialect as the + other compilers on that machine. But such applications are rare. + And users writing a program to run on more than one type of + machine cannot possibly benefit from this kind of compatibility. + + This is why GNU CC does and will treat plain bitfields in the same + fashion on all types of machines (by default). + + There are some arguments for making bitfields unsigned by default + on all machines. If, for example, this becomes a universal de + facto standard, it would make sense for GNU CC to go along with + it. This is something to be considered in the future. + + (Of course, users strongly concerned about portability should + indicate explicitly in each bitfield whether it is signed or not. + In this way, they write programs which have the same meaning in + both C dialects.) + + * Undefining `__STDC__' when `-ansi' is not used. + + Currently, GNU CC defines `__STDC__' as long as you don't use + `-traditional'. This provides good results in practice. + + Programmers normally use conditionals on `__STDC__' to ask whether + it is safe to use certain features of ANSI C, such as function + prototypes or ANSI token concatenation. Since plain `gcc' supports + all the features of ANSI C, the correct answer to these questions + is "yes". + + Some users try to use `__STDC__' to check for the availability of + certain library facilities. This is actually incorrect usage in + an ANSI C program, because the ANSI C standard says that a + conforming freestanding implementation should define `__STDC__' + even though it does not have the library facilities. `gcc -ansi + -pedantic' is a conforming freestanding implementation, and it is + therefore required to define `__STDC__', even though it does not + come with an ANSI C library. + + Sometimes people say that defining `__STDC__' in a compiler that + does not completely conform to the ANSI C standard somehow + violates the standard. This is illogical. The standard is a + standard for compilers that claim to support ANSI C, such as `gcc + -ansi'--not for other compilers such as plain `gcc'. Whatever the + ANSI C standard says is relevant to the design of plain `gcc' + without `-ansi' only for pragmatic reasons, not as a requirement. + + * Undefining `__STDC__' in C++. + + Programs written to compile with C++-to-C translators get the + value of `__STDC__' that goes with the C compiler that is + subsequently used. These programs must test `__STDC__' to + determine what kind of C preprocessor that compiler uses: whether + they should concatenate tokens in the ANSI C fashion or in the + traditional fashion. + + These programs work properly with GNU C++ if `__STDC__' is defined. + They would not work otherwise. + + In addition, many header files are written to provide prototypes + in ANSI C but not in traditional C. Many of these header files + can work without change in C++ provided `__STDC__' is defined. If + `__STDC__' is not defined, they will all fail, and will all need + to be changed to test explicitly for C++ as well. + + * Deleting "empty" loops. + + GNU CC does not delete "empty" loops because the most likely reason + you would put one in a program is to have a delay. Deleting them + will not make real programs run any faster, so it would be + pointless. + + It would be different if optimization of a nonempty loop could + produce an empty one. But this generally can't happen. + + * Making side effects happen in the same order as in some other + compiler. + + It is never safe to depend on the order of evaluation of side + effects. For example, a function call like this may very well + behave differently from one compiler to another: + + void func (int, int); + + int i = 2; + func (i++, i++); + + There is no guarantee (in either the C or the C++ standard language + definitions) that the increments will be evaluated in any + particular order. Either increment might happen first. `func' + might get the arguments `3, 4', or it might get `4, 3', or even + `3, 3'. + + * Not allowing structures with volatile fields in registers. + + Strictly speaking, there is no prohibition in the ANSI C standard + against allowing structures with volatile fields in registers, but + it does not seem to make any sense and is probably not what you + wanted to do. So the compiler will give an error message in this + case. + + +File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble + +Warning Messages and Error Messages +=================================== + + The GNU compiler can produce two kinds of diagnostics: errors and +warnings. Each kind has a different purpose: + + *Errors* report problems that make it impossible to compile your + program. GNU CC reports errors with the source file name and line + number where the problem is apparent. + + *Warnings* report other unusual conditions in your code that *may* + indicate a problem, although compilation can (and does) proceed. + Warning messages also report the source file name and line number, + but include the text `warning:' to distinguish them from error + messages. + + Warnings may indicate danger points where you should check to make +sure that your program really does what you intend; or the use of +obsolete features; or the use of nonstandard features of GNU C or C++. +Many warnings are issued only if you ask for them, with one of the `-W' +options (for instance, `-Wall' requests a variety of useful warnings). + + GNU CC always tries to compile your program if possible; it never +gratuituously rejects a program whose meaning is clear merely because +(for instance) it fails to conform to a standard. In some cases, +however, the C and C++ standards specify that certain extensions are +forbidden, and a diagnostic *must* be issued by a conforming compiler. +The `-pedantic' option tells GNU CC to issue warnings in such cases; +`-pedantic-errors' says to make them errors instead. This does not +mean that *all* non-ANSI constructs get warnings or errors. + + *Note Options to Request or Suppress Warnings: Warning Options, for +more detail on these and related command-line options. + + +File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top + +Reporting Bugs +************** + + Your bug reports play an essential role in making GNU CC reliable. + + When you encounter a problem, the first thing to do is to see if it +is already known. *Note Trouble::. If it isn't known, then you should +report the problem. + + Reporting a bug may help you by bringing a solution to your problem, +or it may not. (If it does not, look in the service directory; see +*Note Service::.) In any case, the principal function of a bug report +is to help the entire community by making the next version of GNU CC +work better. Bug reports are your contribution to the maintenance of +GNU CC. + + Since the maintainers are very overloaded, we cannot respond to every +bug report. However, if the bug has not been fixed, we are likely to +send you a patch and ask you to tell us whether it works. + + In order for a bug report to serve its purpose, you must include the +information that makes for fixing the bug. + +* Menu: + +* Criteria: Bug Criteria. Have you really found a bug? +* Where: Bug Lists. Where to send your bug report. +* Reporting: Bug Reporting. How to report a bug effectively. +* Patches: Sending Patches. How to send a patch for GNU CC. +* Known: Trouble. Known problems. +* Help: Service. Where to ask for help. + + +File: gcc.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs + +Have You Found a Bug? +===================== + + If you are not sure whether you have found a bug, here are some +guidelines: + + * If the compiler gets a fatal signal, for any input whatever, that + is a compiler bug. Reliable compilers never crash. + + * If the compiler produces invalid assembly code, for any input + whatever (except an `asm' statement), that is a compiler bug, + unless the compiler reports errors (not just warnings) which would + ordinarily prevent the assembler from being run. + + * If the compiler produces valid assembly code that does not + correctly execute the input source code, that is a compiler bug. + + However, you must double-check to make sure, because you may have + run into an incompatibility between GNU C and traditional C (*note + Incompatibilities::.). These incompatibilities might be considered + bugs, but they are inescapable consequences of valuable features. + + Or you may have a program whose behavior is undefined, which + happened by chance to give the desired results with another C or + C++ compiler. + + For example, in many nonoptimizing compilers, you can write `x;' + at the end of a function instead of `return x;', with the same + results. But the value of the function is undefined if `return' + is omitted; it is not a bug when GNU CC produces different results. + + Problems often result from expressions with two increment + operators, as in `f (*p++, *p++)'. Your previous compiler might + have interpreted that expression the way you intended; GNU CC might + interpret it another way. Neither compiler is wrong. The bug is + in your code. + + After you have localized the error to a single source line, it + should be easy to check for these things. If your program is + correct and well defined, you have found a compiler bug. + + * If the compiler produces an error message for valid input, that is + a compiler bug. + + * If the compiler does not produce an error message for invalid + input, that is a compiler bug. However, you should note that your + idea of "invalid input" might be my idea of "an extension" or + "support for traditional practice". + + * If you are an experienced user of C or C++ compilers, your + suggestions for improvement of GNU CC or GNU C++ are welcome in + any case.  -File: gcc.info, Node: Jump Patterns, Next: Insn Canonicalizations, Prev: Dependent Patterns, Up: Machine Desc +File: gcc.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs -Defining Jump Instruction Patterns -================================== +Where to Report Bugs +==================== - For most machines, GNU CC assumes that the machine has a condition -code. A comparison insn sets the condition code, recording the -results of both signed and unsigned comparison of the given operands. -A separate branch insn tests the condition code and branches or not -according its value. The branch insns come in distinct signed and -unsigned flavors. Many common machines, such as the Vax, the 68000 -and the 32000, work this way. - - Some machines have distinct signed and unsigned compare -instructions, and only one set of conditional branch instructions. -The easiest way to handle these machines is to treat them just like -the others until the final stage where assembly code is written. At -this time, when outputting code for the compare instruction, peek -ahead at the following branch using `next_cc0_user (insn)'. (The -variable `insn' refers to the insn being output, in the output-writing -code in an instruction pattern.) If the RTL says that is an unsigned -branch, output an unsigned compare; otherwise output a signed compare. - When the branch itself is output, you can treat signed and unsigned -branches identically. - - The reason you can do this is that GNU CC always generates a pair of -consecutive RTL insns, possibly separated by `note' insns, one to set -the condition code and one to test it, and keeps the pair inviolate -until the end. - - To go with this technique, you must define the machine-description -macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no -compare instruction is superfluous. - - Some machines have compare-and-branch instructions and no condition -code. A similar technique works for them. When it is time to -"output" a compare instruction, record its operands in two static -variables. When outputting the branch-on-condition-code instruction -that follows, actually output a compare-and-branch instruction that -uses the remembered operands. - - It also works to define patterns for compare-and-branch -instructions. In optimizing compilation, the pair of compare and -branch instructions will be combined according to these patterns. But -this does not happen if optimization is not requested. So you must -use one of the solutions above in addition to any special patterns you -define. - - In many RISC machines, most instructions do not affect the condition -code and there may not even be a separate condition code register. On -these machines, the restriction that the definition and use of the -condition code be adjacent insns is not necessary and can prevent -important optimizations. For example, on the IBM RS/6000, there is a -delay for taken branches unless the condition code register is set -three instructions earlier than the conditional branch. The -instruction scheduler cannot perform this optimization if it is not -permitted to separate the definition and use of the condition code -register. - - On these machines, do not use `(cc0)', but instead use a register -to represent the condition code. If there is a specific condition code -register in the machine, use a hard register. If the condition code or -comparison result can be placed in any general register, or if there -are multiple condition registers, use a pseudo register. - - On some machines, the type of branch instruction generated may -depend on the way the condition code was produced; for example, on the -68k and Sparc, setting the condition code directly from an add or -subtract instruction does not clear the overflow bit the way that a -test instruction does, so a different branch instruction must be used -for some conditional branches. For machines that use `(cc0)', the set -and use of the condition code must be adjacent (separated only by -`note' insns) allowing flags in `cc_status' to be used. (*Note -Condition Code::.) Also, the comparison and branch insns can be -located from each other by using the functions `prev_cc0_setter' and -`next_cc0_user'. - - However, this is not true on machines that do not use `(cc0)'. On -those machines, no assumptions can be made about the adjacency of the -compare and branch insns and the above methods cannot be used. -Instead, we use the machine mode of the condition code register to -record different formats of the condition code register. - - Registers used to store the condition code value should have a mode -that is in class `MODE_CC'. Normally, it will be `CCmode'. If -additional modes are required (as for the add example mentioned above -in the Sparc), define the macro `EXTRA_CC_MODES' to list the -additional modes required (*note Condition Code::.). Also define -`EXTRA_CC_NAMES' to list the names of those modes and `SELECT_CC_MODE' -to choose a mode given an operand of a compare. - - If it is known during RTL generation that a different mode will be -required (for example, if the machine has separate compare instructions -for signed and unsigned quantities, like most IBM processors), they can -be specified at that time. - - If the cases that require different modes would be made by -instruction combination, the macro `SELECT_CC_MODE' determines which -machine mode should be used for the comparison result. The patterns -should be written using that mode. To support the case of the add on -the Sparc discussed above, we have the pattern - - (define_insn "" - [(set (reg:CC_NOOV 0) - (compare:CC_NOOV (plus:SI (match_operand:SI 0 "register_operand" "%r") - (match_operand:SI 1 "arith_operand" "rI")) - (const_int 0)))] - "" - "...") + Send bug reports for GNU C to `bug-gcc@prep.ai.mit.edu'. - The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for -comparisons whose argument is a `plus'. + Send bug reports for GNU C++ to `bug-g++@prep.ai.mit.edu'. If your +bug involves the C++ class library libg++, send mail to +`bug-lib-g++@prep.ai.mit.edu'. If you're not sure, you can send the +bug report to both lists. + + *Do not send bug reports to `help-gcc@prep.ai.mit.edu' or to the +newsgroup `gnu.gcc.help'.* Most users of GNU CC do not want to receive +bug reports. Those that do, have asked to be on `bug-gcc' and/or +`bug-g++'. + + The mailing lists `bug-gcc' and `bug-g++' both have newsgroups which +serve as repeaters: `gnu.gcc.bug' and `gnu.g++.bug'. Each mailing list +and its newsgroup carry exactly the same messages. + + Often people think of posting bug reports to the newsgroup instead of +mailing them. This appears to work, but it has one problem which can be +crucial: a newsgroup posting does not contain a mail path back to the +sender. Thus, if maintainers need more information, they may be unable +to reach you. For this reason, you should always send bug reports by +mail to the proper mailing list. + + As a last resort, send bug reports on paper to: + + GNU Compiler Bugs + Free Software Foundation + 675 Mass Ave + Cambridge, MA 02139 - \ No newline at end of file