--- gcc/gcc.info-10 2018/04/24 17:51:21 1.1 +++ gcc/gcc.info-10 2018/04/24 18:24:16 1.1.1.8 @@ -1,1120 +1,869 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 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: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc +File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Extended Asm, Up: C Extensions + +Controlling Names Used in Assembler Code +======================================== + + You can specify the name to be used in the assembler code for a C +function or variable by writing the `asm' (or `__asm__') keyword after +the declarator as follows: + + int foo asm ("myfoo") = 2; + +This specifies that the name to be used for the variable `foo' in the +assembler code should be `myfoo' rather than the usual `_foo'. + + On systems where an underscore is normally prepended to the name of +a C function or variable, this feature allows you to define names for +the linker that do not start with an underscore. -Standard Names for Patterns Used in Generation -============================================== + You cannot use `asm' in this way in a function *definition*; but you +can get the same effect by writing a declaration for the function +before its definition and putting `asm' there, like this: - 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. + extern func () asm ("FUNC"); + + func (x, y) + int x, y; + ... + + It is up to you to make sure that the assembler names you choose do +not conflict with any other assembler symbols. Also, you must not use a +register name; that would produce completely invalid assembler code. +GNU CC does not as yet have the ability to store static variables in +registers. Perhaps that will be added.  -File: gcc.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc +File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: C Extensions + +Variables in Specified Registers +================================ -When the Order of Patterns Matters -================================== + GNU C allows you to put a few global variables into specified +hardware registers. You can also specify the register in which an +ordinary register variable should be allocated. + + * Global register variables reserve registers throughout the program. + This may be useful in programs such as programming language + interpreters which have a couple of global variables that are + accessed very often. + + * Local register variables in specific registers do not reserve the + registers. The compiler's data flow analysis is capable of + determining where the specified registers contain live values, and + where they are available for other uses. + + These local variables are sometimes convenient for use with the + extended `asm' feature (*note Extended Asm::.), if you want to + write one output of the assembler instruction directly into a + particular register. (This will work provided the register you + specify fits the constraints specified for that operand in the + `asm'.) - 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. +* Menu: + +* Global Reg Vars:: +* Local Reg Vars::  -File: gcc.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc +File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars -Interdependence of Patterns -=========================== +Defining Global Register Variables +---------------------------------- - 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 + You can define a global register variable in GNU C like this: - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:HI 1 ...))) - - (set (match_operand:SI 0 ...) - (extend:SI (match_operand:QI 1 ...))) + register int *foo asm ("a5"); + +Here `a5' is the name of the register which should be used. Choose a +register which is normally saved and restored by function calls on your +machine, so that library routines will not clobber it. + + Naturally the register name is cpu-dependent, so you would need to +conditionalize your program according to cpu type. The register `a5' +would be a good choice on a 68000 for a variable of pointer type. On +machines with register windows, be sure to choose a "global" register +that is not affected magically by the function call mechanism. + + In addition, operating systems on one type of cpu may differ in how +they name the registers; then you would need additional conditionals. +For example, some 68000 operating systems call this register `%a5'. + + Eventually there may be a way of asking the compiler to choose a +register automatically, but first we need to figure out how it should +choose and how to enable you to guide the choice. No solution is +evident. + + Defining a global register variable in a certain register reserves +that register entirely for this use, at least within the current +compilation. The register will not be allocated for any other purpose +in the functions in the current compilation. The register will not be +saved and restored by these functions. Stores into this register are +never deleted even if they would appear to be dead, but references may +be deleted or moved or simplified. + + It is not safe to access the global register variables from signal +handlers, or from more than one thread of control, because the system +library routines may temporarily use the register for other things +(unless you recompile them specially for the task at hand). + + It is not safe for one function that uses a global register variable +to call another such function `foo' by way of a third function `lose' +that was compiled without knowledge of this variable (i.e. in a +different source file in which the variable wasn't declared). This is +because `lose' might save the register and put some other value there. +For example, you can't expect a global register variable to be +available in the comparison-function that you pass to `qsort', since +`qsort' might have put something else in that register. (If you are +prepared to recompile `qsort' with the same global register variable, +you can solve this problem.) + + If you want to recompile `qsort' or other source files which do not +actually use your global register variable, so that they will not use +that register for any other purpose, then it suffices to specify the +compiler option `-ffixed-REG'. You need not actually add a global +register declaration to their source code. + + A function which can alter the value of a global register variable +cannot safely be called from a function compiled without this variable, +because it could clobber the value the caller expects to find there on +return. Therefore, the function which is the entry point into the part +of the program that uses the global register variable must explicitly +save and restore the value which belongs to its caller. + + On most machines, `longjmp' will restore to each global register +variable the value it had at the time of the `setjmp'. On some +machines, however, `longjmp' will not change the value of global +register variables. To be portable, the function that called `setjmp' +should make other arrangements to save the values of the global register +variables, and to restore them in a `longjmp'. This way, the same +thing will happen regardless of what `longjmp' does. + + All global register variable declarations must precede all function +definitions. If such a declaration could appear after function +definitions, the declaration would be too late to prevent the register +from being used for other purposes in the preceding functions. + + Global register variables may not have initial values, because an +executable file has no means to supply initial contents for a register. + + On the Sparc, there are reports that g3 ... g7 are suitable +registers, but certain library functions, such as `getwd', as well as +the subroutines for division and remainder, modify g3 and g4. g1 and +g2 are local temporaries. -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. + On the 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of +course, it will not do to use more than a few of those.  -File: gcc.info, Node: Jump Patterns, Next: Insn Canonicalizations, Prev: Dependent Patterns, Up: Machine Desc +File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars -Defining Jump Instruction Patterns -================================== +Specifying Registers for Local Variables +---------------------------------------- - 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)))] - "" - "...") + You can define a local register variable with a specified register +like this: - The `SELECT_CC_MODE' macro on the Sparc returns `CC_NOOVmode' for -comparisons whose argument is a `plus'. + register int *foo asm ("a5"); + +Here `a5' is the name of the register which should be used. Note that +this is the same syntax used for defining global register variables, +but for a local variable it would appear within a function. + + Naturally the register name is cpu-dependent, but this is not a +problem, since specific registers are most often useful with explicit +assembler instructions (*note Extended Asm::.). Both of these things +generally require that you conditionalize your program according to cpu +type. + + In addition, operating systems on one type of cpu may differ in how +they name the registers; then you would need additional conditionals. +For example, some 68000 operating systems call this register `%a5'. + + Eventually there may be a way of asking the compiler to choose a +register automatically, but first we need to figure out how it should +choose and how to enable you to guide the choice. No solution is +evident. + + Defining such a register variable does not reserve the register; it +remains available for other uses in places where flow control determines +the variable's value is not live. However, these registers are made +unavailable for use in the reload pass. I would not be surprised if +excessive use of this feature leaves the compiler too few available +registers to compile certain functions.  -File: gcc.info, Node: Insn Canonicalizations, Next: Peephole Definitions, Prev: Jump Patterns, Up: Machine Desc +File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions -Canonicalization of Instructions -================================ +Alternate Keywords +================== + + The option `-traditional' disables certain keywords; `-ansi' +disables certain others. This causes trouble when you want to use GNU C +extensions, or ANSI C features, in a general-purpose header file that +should be usable by all programs, including ANSI C programs and +traditional ones. The keywords `asm', `typeof' and `inline' cannot be +used since they won't work in a program compiled with `-ansi', while +the keywords `const', `volatile', `signed', `typeof' and `inline' won't +work in a program compiled with `-traditional'. + + The way to solve these problems is to put `__' at the beginning and +end of each problematical keyword. For example, use `__asm__' instead +of `asm', `__const__' instead of `const', and `__inline__' instead of +`inline'. + + Other C compilers won't accept these alternative keywords; if you +want to compile with another compiler, you can define the alternate +keywords as macros to replace them with the customary keywords. It +looks like this: + + #ifndef __GNUC__ + #define __asm__ asm + #endif + + `-pedantic' causes warnings for many GNU C extensions. You can +prevent such warnings within one expression by writing `__extension__' +before the expression. `__extension__' has no effect aside from this. + + +File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions + +Incomplete `enum' Types +======================= + + You can define an `enum' tag without specifying its possible values. +This results in an incomplete type, much like what you get if you write +`struct foo' without describing the elements. A later declaration +which does specify the possible values completes the type. + + You can't allocate variables or storage using the type while it is +incomplete. However, you can work with pointers to that type. + + This extension may not be very useful, but it makes the handling of +`enum' more consistent with the way `struct' and `union' are handled. - There are often cases where multiple RTL expressions could -represent an operation peformed 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 extension is not supported by GNU C++.  -File: gcc.info, Node: Peephole Definitions, Next: Expander Definitions, Prev: Insn Canonicalizations, Up: Machine Desc +File: gcc.info, Node: Function Names, Prev: Incomplete Enums, Up: C Extensions -Defining Machine-Specific Peephole Optimizers -============================================= +Function Names as Strings +========================= - In addition to instruction patterns the `md' file may contain -definitions of machine-specific peephole optimizations. + GNU CC predefines two string variables to be the name of the current +function. The variable `__FUNCTION__' is the name of the function as +it appears in the source. The variable `__PRETTY_FUNCTION__' is the +name of the function pretty printed in a language specific fashion. - 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])" - "* + These names are always the same in a C function, but in a C++ +function they may be different. For example, this program: + + extern "C" { + extern int printf (char *, ...); + } + + class a { + public: + sub (int i) + { + printf ("__FUNCTION__ = %s\n", __FUNCTION__); + printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__); + } + }; + + int + main (void) { - 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 + a ax; + ax.sub (0); + return 0; + } + +gives this output: + + __FUNCTION__ = sub + __PRETTY_FUNCTION__ = int a::sub (int) + + These names are not macros: they are predefined string variables. +For example, `#ifdef __FUNCTION__' does not have any special meaning +inside a function, since the preprocessor does not do anything special +with the identifier `__FUNCTION__'. + + +File: gcc.info, Node: C++ Extensions, Next: Trouble, Prev: C Extensions, Up: Top + +Extensions to the C++ Language +****************************** + + The GNU compiler provides these extensions to the C++ language (and +you can also use most of the C language extensions in your C++ +programs). If you want to write code that checks whether these +features are available, you can test for the GNU compiler the same way +as for C programs: check for a predefined macro `__GNUC__'. You can +also use `__GNUG__' to test specifically for GNU C++ (*note Standard +Predefined Macros: (cpp.info)Standard Predefined.). + +* Menu: + +* Naming Results:: Giving a name to C++ function return values. +* Min and Max:: C++ Minimum and maximum operators. +* Destructors and Goto:: Goto is safe to use in C++ even when destructors + are needed. +* C++ Interface:: You can use a single C++ header file for both + declarations and definitions. +* Template Instantiation:: Methods for ensuring that exactly one copy of + each needed template instantiation is emitted. +* C++ Signatures:: You can specify abstract types to get subtype + polymorphism independent from inheritance. + + +File: gcc.info, Node: Naming Results, Next: Min and Max, Up: C++ Extensions + +Named Return Values in C++ +========================== + + GNU C++ extends the function-definition syntax to allow you to +specify a name for the result of a function outside the body of the +definition, in C++ programs: + + TYPE + FUNCTIONNAME (ARGS) return RESULTNAME; + { + ... + BODY + ... + } + + You can use this feature to avoid an extra constructor call when a +function result has a class type. For example, consider a function +`m', declared as `X v = m ();', whose result is of class `X': + + X + m () + { + X b; + b.a = 23; + return b; + } + + Although `m' appears to have no arguments, in fact it has one +implicit argument: the address of the return value. At invocation, the +address of enough space to hold `v' is sent in as the implicit argument. +Then `b' is constructed and its `a' field is set to the value 23. +Finally, a copy constructor (a constructor of the form `X(X&)') is +applied to `b', with the (implicit) return value location as the +target, so that `v' is now bound to the return value. + + But this is wasteful. The local `b' is declared just to hold +something that will be copied right out. While a compiler that +combined an "elision" algorithm with interprocedural data flow analysis +could conceivably eliminate all of this, it is much more practical to +allow you to assist the compiler in generating efficient code by +manipulating the return value explicitly, thus avoiding the local +variable and copy constructor altogether. + + Using the extended GNU C++ function-definition syntax, you can avoid +the temporary allocation and copying by naming `r' as your return value +at the outset, and assigning to its `a' field directly: + + X + m () return r; + { + r.a = 23; + } + +The declaration of `r' is a standard, proper declaration, whose effects +are executed *before* any of the body of `m'. + + Functions of this type impose no additional restrictions; in +particular, you can execute `return' statements, or return implicitly by +reaching the end of the function body ("falling off the edge"). Cases +like + + X + m () return r (23); + { + return; } - ") - The effect of this optimization is to change +(or even `X m () return r (23); { }') are unambiguous, since the return +value `r' has been initialized in either case. The following code may +be hard to read, but also works predictably: + + X + m () return r; + { + X b; + return b; + } + + The return value slot denoted by `r' is initialized at the outset, +but the statement `return b;' overrides this value. The compiler deals +with this by destroying `r' (calling the destructor if there is one, or +doing nothing if there is not), and then reinitializing `r' with `b'. + + This extension is provided primarily to help people who use +overloaded operators, where there is a great need to control not just +the arguments, but the return values of functions. For classes where +the copy constructor incurs a heavy performance penalty (especially in +the common case where there is a quick default constructor), this is a +major savings. The disadvantage of this extension is that you do not +control when the default constructor for the return value is called: it +is always called at the beginning. + + +File: gcc.info, Node: Min and Max, Next: Destructors and Goto, Prev: Naming Results, Up: C++ Extensions + +Minimum and Maximum Operators in C++ +==================================== + + It is very convenient to have operators which return the "minimum" +or the "maximum" of two arguments. In GNU C++ (but not in GNU C), + +`A ? B' + is the "maximum", returning the larger of the numeric values A and + B. + + These operations are not primitive in ordinary C++, since you can +use a macro to return the minimum of two things in C++, as in the +following example. + + #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y)) + +You might then use `int min = MIN (i, j);' to set MIN to the minimum +value of variables I and J. + + However, side effects in `X' or `Y' may cause unintended behavior. +For example, `MIN (i++, j++)' will fail, incrementing the smaller +counter twice. A GNU C extension allows you to write safe macros that +avoid this kind of problem (*note Naming an Expression's Type: Naming +Types.). However, writing `MIN' and `MAX' as macros also forces you to +use function-call notation notation for a fundamental arithmetic +operation. Using GNU C++ extensions, you can write `int min = i ?' are built into the compiler, they properly +handle expressions with side-effects; `int min = i++ ; + template ostream& operator << (ostream&, const A&); + + This strategy will work with code written for either model. If + you are using code written for the Cfront model, the file + containing a class template and the file containing its member + templates should be implemented in the same translation unit. + + A slight variation on this approach is to use the flag + -falt-external-templates instead; this flag causes template + instances to be emitted in the translation unit that implements + the header where they are first instantiated, rather than the one + which implements the file where the templates are defined. This + header must be the same in all translation units, or things are + likely to break. + + *Note Declarations and Definitions in One Header: C++ Interface, + for more discussion of these pragmas. + + 3. Explicitly instantiate all the template instances you use, and + compile with -fno-implicit-templates. This is probably your best + bet; it may require more knowledge of exactly which templates you + are using, but it's less mysterious than the previous approach, + and it doesn't require any `#pragma's or other g++-specific code. + You can scatter the instantiations throughout your program, you + can create one big file to do all the instantiations, or you can + create tiny files like + + #include "Foo.h" + #include "Foo.cc" + + template class Foo; + + for each instance you need, and create a template instantiation + library from those. I'm partial to the last, but your mileage may + vary. If you are using Cfront-model code, you can probably get + away with not using -fno-implicit-templates when compiling files + that don't `#include' the member template definitions. + + +File: gcc.info, Node: C++ Signatures, Prev: Template Instantiation, Up: C++ Extensions + +Type Abstraction using Signatures +================================= + + In GNU C++, you can use the keyword `signature' to define a +completely abstract class interface as a datatype. You can connect this +abstraction with actual classes using signature pointers. If you want +to use signatures, run the GNU compiler with the `-fhandle-signatures' +command-line option. (With this option, the compiler reserves a second +keyword `sigof' as well, for a future extension.) + + Roughly, signatures are type abstractions or interfaces of classes. +Some other languages have similar facilities. C++ signatures are +related to ML's signatures, Haskell's type classes, definition modules +in Modula-2, interface modules in Modula-3, abstract types in Emerald, +type modules in Trellis/Owl, categories in Scratchpad II, and types in +POOL-I. For a more detailed discussion of signatures, see `Signatures: +A Language Extension for Improving Type Abstraction and Subtype +Polymorphism in C++' by Gerald Baumgartner and Vincent F. Russo (Tech +report CSD-TR-95-051, Dept. of Computer Sciences, Purdue University, +August 1995, a slightly improved version appeared in +*Software--Practice & Experience*, 25(8), pp. 863-889, August 1995). +You can get the tech report by anonymous FTP from `ftp.cs.purdue.edu' +in `pub/gb/Signature-design.ps.gz'. + + Syntactically, a signature declaration is a collection of member +function declarations and nested type declarations. For example, this +signature declaration defines a new abstract type `S' with member +functions `int foo ()' and `int bar (int)': + + signature S { - 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. + int foo (); + int bar (int); + }; + + Since signature types do not include implementation definitions, you +cannot write an instance of a signature directly. Instead, you can +define a pointer to any class that contains the required interfaces as a +"signature pointer". Such a class "implements" the signature type. + + To use a class as an implementation of `S', you must ensure that the +class has public member functions `int foo ()' and `int bar (int)'. +The class can have other member functions as well, public or not; as +long as it offers what's declared in the signature, it is suitable as +an implementation of that signature type. + + For example, suppose that `C' is a class that meets the requirements +of signature `S' (`C' "conforms to" `S'). Then + + C obj; + S * p = &obj; + +defines a signature pointer `p' and initializes it to point to an +object of type `C'. The member function call `int i = p->foo ();' +executes `obj.foo ()'. + + Abstract virtual classes provide somewhat similar facilities in +standard C++. There are two main advantages to using signatures +instead: + + 1. Subtyping becomes independent from inheritance. A class or + signature type `T' is a subtype of a signature type `S' + independent of any inheritance hierarchy as long as all the member + functions declared in `S' are also found in `T'. So you can + define a subtype hierarchy that is completely independent from any + inheritance (implementation) hierarchy, instead of being forced to + use types that mirror the class inheritance hierarchy. + + 2. Signatures allow you to work with existing class hierarchies as + implementations of a signature type. If those class hierarchies + are only available in compiled form, you're out of luck with + abstract virtual classes, since an abstract virtual class cannot + be retrofitted on top of existing class hierarchies. So you would + be required to write interface classes as subtypes of the abstract + virtual class. + + There is one more detail about signatures. A signature declaration +can contain member function *definitions* as well as member function +declarations. A signature member function with a full definition is +called a *default implementation*; classes need not contain that +particular interface in order to conform. For example, a class `C' can +conform to the signature + + signature T + { + int f (int); + int f0 () { return f (0); }; + }; + +whether or not `C' implements the member function `int f0 ()'. If you +define `C::f0', that definition takes precedence; otherwise, the +default implementation `S::f0' applies. + + +File: gcc.info, Node: Trouble, Next: Bugs, Prev: C++ Extensions, Up: Top + +Known Causes of Trouble with GNU CC +*********************************** + + This section describes known problems that affect users of GNU CC. +Most of these are not GNU CC bugs per se--if they were, we would fix +them. But the result for a user may be like the result of a bug. + + Some of these problems are due to bugs in other software, some are +missing features that are too much work to add, and some are places +where people's opinions differ as to what is best. + +* Menu: + +* Actual Bugs:: Bugs we will fix later. +* Installation Problems:: Problems that manifest when you install GNU CC. +* Cross-Compiler Problems:: Common problems of cross compiling with GNU CC. +* Interoperation:: Problems using GNU CC with other compilers, + and with certain linkers, assemblers and debuggers. +* External Bugs:: Problems compiling certain programs. +* Incompatibilities:: GNU CC is incompatible with traditional C. +* Fixed Headers:: GNU C uses corrected versions of system header files. + This is necessary, but doesn't always work smoothly. +* Standard Libraries:: GNU C uses the system C library, which might not be + compliant with the ISO/ANSI C standard. +* Disappointments:: Regrettable things we can't change, but not quite bugs. +* C++ Misunderstandings:: Common misunderstandings with GNU C++. +* Protoize Caveats:: Things to watch out for when using `protoize'. +* Non-bugs:: Things we think are right, but some others disagree. +* Warnings and Errors:: Which problems in your code get warnings, + and which get errors. + + +File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble + +Actual Bugs We Haven't Fixed Yet +================================ + + * The `fixincludes' script interacts badly with automounters; if the + directory of system header files is automounted, it tends to be + unmounted while `fixincludes' is running. This would seem to be a + bug in the automounter. We don't know any good way to work around + it. + + * The `fixproto' script will sometimes add prototypes for the + `sigsetjmp' and `siglongjmp' functions that reference the + `jmp_buf' type before that type is defined. To work around this, + edit the offending file and place the typedef in front of the + prototypes. + + * There are several obscure case of mis-using struct, union, and + enum tags that are not detected as errors by the compiler. + + * When `-pedantic-errors' is specified, GNU C will incorrectly give + an error message when a function name is specified in an expression + involving the comma operator. + + * Loop unrolling doesn't work properly for certain C++ programs. + This is a bug in the C++ front end. It sometimes emits incorrect + debug info, and the loop unrolling code is unable to recover from + this error. - \ No newline at end of file