--- gcc/gcc.info-10 2018/04/24 18:00:53 1.1.1.4 +++ gcc/gcc.info-10 2018/04/24 18:24:16 1.1.1.8 @@ -1,9 +1,13 @@ -This is Info file gcc.info, produced by Makeinfo-1.49 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 + + 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 @@ -11,1071 +15,855 @@ preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also -that the sections entitled "GNU General Public License" and "Protect -Your Freedom--Fight `Look And Feel'" are included exactly as in the -original, and provided that the entire resulting derived work is -distributed under the terms of a permission notice identical to this -one. +that the sections entitled "GNU General Public License," "Funding for +Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are +included exactly as in the original, and provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the sections entitled "GNU General Public -License" and "Protect Your Freedom--Fight `Look And Feel'", and this -permission notice, may be included in translations approved by the Free -Software Foundation instead of in the original English. +License," "Funding for Free Software," and "Protect Your Freedom--Fight +`Look And Feel'", and this permission notice, may be included in +translations approved by the Free Software Foundation instead of in the +original English.  -File: gcc.info, Node: Conversions, Next: RTL Declarations, Prev: Bit Fields, Up: RTL +File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Extended Asm, Up: C Extensions -Conversions -=========== +Controlling Names Used in Assembler Code +======================================== - All conversions between machine modes must be represented by -explicit conversion operations. For example, an expression which is -the sum of a byte and a full word cannot be written as `(plus:SI -(reg:QI 34) (reg:SI 80))' because the `plus' operation requires two -operands of the same machine mode. Therefore, the byte-sized operand is -enclosed in a conversion operation, as in - - (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) - - The conversion operation is not a mere placeholder, because there -may be more than one way of converting from a given starting mode to -the desired final mode. The conversion operation code says how to do -it. - - For all conversion operations, X must not be `VOIDmode' because the -mode in which to do the conversion would not be known. The conversion -must either be done at compile-time or X must be placed into a register. - -`(sign_extend:M X)' - Represents the result of sign-extending the value X to machine - mode M. M must be a fixed-point mode and X a fixed-point value of - a mode narrower than M. - -`(zero_extend:M X)' - Represents the result of zero-extending the value X to machine - mode M. M must be a fixed-point mode and X a fixed-point value of - a mode narrower than M. - -`(float_extend:M X)' - Represents the result of extending the value X to machine mode M. - M must be a floating point mode and X a floating point value of a - mode narrower than M. - -`(truncate:M X)' - Represents the result of truncating the value X to machine mode M. - M must be a fixed-point mode and X a fixed-point value of a mode - wider than M. - -`(float_truncate:M X)' - Represents the result of truncating the value X to machine mode M. - M must be a floating point mode and X a floating point value of a - mode wider than M. - -`(float:M X)' - Represents the result of converting fixed point value X, regarded - as signed, to floating point mode M. - -`(unsigned_float:M X)' - Represents the result of converting fixed point value X, regarded - as unsigned, to floating point mode M. - -`(fix:M X)' - When M is a fixed point mode, represents the result of converting - floating point value X to mode M, regarded as signed. How - rounding is done is not specified, so this operation may be used - validly in compiling C code only for integer-valued operands. - -`(unsigned_fix:M X)' - Represents the result of converting floating point value X to - fixed point mode M, regarded as unsigned. How rounding is done is - not specified. - -`(fix:M X)' - When M is a floating point mode, represents the result of - converting floating point value X (valid for mode M) to an - integer, still represented in floating point mode M, by rounding - towards zero. + 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. + + 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: + + 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: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL +File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: C Extensions + +Variables in Specified Registers +================================ -Declarations -============ + 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'.) - Declaration expression codes do not represent arithmetic operations -but rather state assertions about their operands. +* Menu: -`(strict_low_part (subreg:M (reg:N R) 0))' - This expression code is used in only one context: as the - destination operand of a `set' expression. In addition, the - operand of this expression must be a non-paradoxical `subreg' - expression. - - The presence of `strict_low_part' says that the part of the - register which is meaningful in mode N, but is not part of mode M, - is not to be altered. Normally, an assignment to such a subreg is - allowed to have undefined effects on the rest of the register when - M is less than a word. +* Global Reg Vars:: +* Local Reg Vars::  -File: gcc.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL +File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars + +Defining Global Register Variables +---------------------------------- + + You can define a global register variable in GNU C like this: + + 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. + + 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: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars + +Specifying Registers for Local Variables +---------------------------------------- -Side Effect Expressions + You can define a local register variable with a specified register +like this: + + register int *foo asm ("a5"); + +Here `a5' is the name of the register which should be used. Note that +this is the same syntax used for defining global register variables, +but for a local variable it would appear within a function. + + Naturally the register name is cpu-dependent, but this is not a +problem, since specific registers are most often useful with explicit +assembler instructions (*note Extended Asm::.). Both of these things +generally require that you conditionalize your program according to cpu +type. + + In addition, operating systems on one type of cpu may differ in how +they name the registers; then you would need additional conditionals. +For example, some 68000 operating systems call this register `%a5'. + + Eventually there may be a way of asking the compiler to choose a +register automatically, but first we need to figure out how it should +choose and how to enable you to guide the choice. No solution is +evident. + + Defining such a register variable does not reserve the register; it +remains available for other uses in places where flow control determines +the variable's value is not live. However, these registers are made +unavailable for use in the reload pass. I would not be surprised if +excessive use of this feature leaves the compiler too few available +registers to compile certain functions. + + +File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions + +Alternate Keywords +================== + + The option `-traditional' disables certain keywords; `-ansi' +disables certain others. This causes trouble when you want to use GNU C +extensions, or ANSI C features, in a general-purpose header file that +should be usable by all programs, including ANSI C programs and +traditional ones. The keywords `asm', `typeof' and `inline' cannot be +used since they won't work in a program compiled with `-ansi', while +the keywords `const', `volatile', `signed', `typeof' and `inline' won't +work in a program compiled with `-traditional'. + + The way to solve these problems is to put `__' at the beginning and +end of each problematical keyword. For example, use `__asm__' instead +of `asm', `__const__' instead of `const', and `__inline__' instead of +`inline'. + + Other C compilers won't accept these alternative keywords; if you +want to compile with another compiler, you can define the alternate +keywords as macros to replace them with the customary keywords. It +looks like this: + + #ifndef __GNUC__ + #define __asm__ asm + #endif + + `-pedantic' causes warnings for many GNU C extensions. You can +prevent such warnings within one expression by writing `__extension__' +before the expression. `__extension__' has no effect aside from this. + + +File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions + +Incomplete `enum' Types ======================= - The expression codes described so far represent values, not actions. -But machine instructions never produce values; they are meaningful only -for their side effects on the state of the machine. Special expression -codes are used to represent side effects. - - The body of an instruction is always one of these side effect codes; -the codes described above, which represent values, appear only as the -operands of these. - -`(set LVAL X)' - Represents the action of storing the value of X into the place - represented by LVAL. LVAL must be an expression representing a - place that can be stored in: `reg' (or `subreg' or - `strict_low_part'), `mem', `pc' or `cc0'. - - If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then - X must be valid for that mode. - - If LVAL is a `reg' whose machine mode is less than the full width - of the register, then it means that the part of the register - specified by the machine mode is given the specified value and the - rest of the register receives an undefined value. Likewise, if - LVAL is a `subreg' whose machine mode is narrower than the mode of - the register, the rest of the register can be changed in an - undefined way. - - If LVAL is a `strict_low_part' of a `subreg', then the part of the - register specified by the machine mode of the `subreg' is given - the value X and the rest of the register is not changed. - - If LVAL is `(cc0)', it has no machine mode, and X may be either a - `compare' expression or a value that may have any mode. The latter - case represents a "test" instruction. The expression `(set (cc0) - (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) - (const_int 0)))'. Use the former expression to save space during - the compilation. - - If LVAL is `(pc)', we have a jump instruction, and the - possibilities for X are very limited. It may be a `label_ref' - expression (unconditional jump). It may be an `if_then_else' - (conditional jump), in which case either the second or the third - operand must be `(pc)' (for the case which does not jump) and the - other of the two must be a `label_ref' (for the case which does - jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may - be a `reg' or a `mem'; these unusual patterns are used to - represent jumps through branch tables. - - If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not - be `VOIDmode' and the mode of X must be valid for the mode of LVAL. - - LVAL is customarily accessed with the `SET_DEST' macro and X with - the `SET_SRC' macro. - -`(return)' - As the sole expression in a pattern, represents a return from the - current function, on machines where this can be done with one - instruction, such as Vaxes. On machines where a multi-instruction - "epilogue" must be executed in order to return from the function, - returning is done by jumping to a label which precedes the - epilogue, and the `return' expression code is never used. - - Inside an `if_then_else' expression, represents the value to be - placed in `pc' to return to the caller. - - Note that an insn pattern of `(return)' is logically equivalent to - `(set (pc) (return))', but the latter form is never used. - -`(call FUNCTION NARGS)' - Represents a function call. FUNCTION is a `mem' expression whose - address is the address of the function to be called. NARGS is an - expression which can be used for two purposes: on some machines it - represents the number of bytes of stack argument; on others, it - represents the number of argument registers. - - Each machine has a standard machine mode which FUNCTION must have. - The machine description defines macro `FUNCTION_MODE' to expand - into the requisite mode name. The purpose of this mode is to - specify what kind of addressing is allowed, on machines where the - allowed kinds of addressing depend on the machine mode being - addressed. - -`(clobber X)' - Represents the storing or possible storing of an unpredictable, - undescribed value into X, which must be a `reg', `scratch' or - `mem' expression. - - One place this is used is in string instructions that store - standard values into particular hard registers. It may not be - worth the trouble to describe the values that are stored, but it - is essential to inform the compiler that the registers will be - altered, lest it attempt to keep data in them across the string - instruction. - - If X is `(mem:BLK (const_int 0))', it means that all memory - locations must be presumed clobbered. - - Note that the machine description classifies certain hard - registers as "call-clobbered". All function call instructions are - assumed by default to clobber these registers, so there is no need - to use `clobber' expressions to indicate this fact. Also, each - function call is assumed to have the potential to alter any memory - location, unless the function is declared `const'. - - If the last group of expressions in a `parallel' are each a - `clobber' expression whose arguments are `reg' or `match_scratch' - (*note RTL Template::.) expressions, the combiner phase can add - the appropriate `clobber' expressions to an insn it has - constructed when doing so will cause a pattern to be matched. - - This feature can be used, for example, on a machine that whose - multiply and add instructions don't use an MQ register but which - has an add-accumulate instruction that does clobber the MQ - register. Similarly, a combined instruction might require a - temporary register while the constituent instructions might not. - - When a `clobber' expression for a register appears inside a - `parallel' with other side effects, the register allocator - guarantees that the register is unoccupied both before and after - that insn. However, the reload phase may allocate a register used - for one of the inputs unless the `&' constraint is specified for - the selected alternative (*note Modifiers::.). You can clobber - either a specific hard register, a pseudo register, or a `scratch' - expression; in the latter two cases, GNU CC will allocate a hard - register that is available there for use as a temporary. - - For instructions that require a temporary register, you should use - `scratch' instead of a pseudo-register because this will allow the - combiner phase to add the `clobber' when required. You do this by - coding (`clobber' (`match_scratch' ...)). If you do clobber a - pseudo register, use one which appears nowhere else--generate a - new one each time. Otherwise, you may confuse CSE. - - There is one other known use for clobbering a pseudo register in a - `parallel': when one of the input operands of the insn is also - clobbered by the insn. In this case, using the same pseudo - register in the clobber and elsewhere in the insn produces the - expected results. - -`(use X)' - Represents the use of the value of X. It indicates that the value - in X at this point in the program is needed, even though it may - not be apparent why this is so. Therefore, the compiler will not - attempt to delete previous instructions whose only effect is to - store a value in X. X must be a `reg' expression. - - During the delayed branch scheduling phase, X may be an insn. This - indicates that X previously was located at this place in the code - and its data dependencies need to be taken into account. These - `use' insns will be deleted before the delayed branch scheduling - phase exits. - -`(parallel [X0 X1 ...])' - Represents several side effects performed in parallel. The square - brackets stand for a vector; the operand of `parallel' is a vector - of expressions. X0, X1 and so on are individual side effect - expressions--expressions of code `set', `call', `return', - `clobber' or `use'. - - "In parallel" means that first all the values used in the - individual side-effects are computed, and second all the actual - side-effects are performed. For example, - - (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) - (set (mem:SI (reg:SI 1)) (reg:SI 1))]) - - says unambiguously that the values of hard register 1 and the - memory location addressed by it are interchanged. In both places - where `(reg:SI 1)' appears as a memory address it refers to the - value in register 1 *before* the execution of the insn. - - It follows that it is *incorrect* to use `parallel' and expect the - result of one `set' to be available for the next one. For example, - people sometimes attempt to represent a jump-if-zero instruction - this way: - - (parallel [(set (cc0) (reg:SI 34)) - (set (pc) (if_then_else - (eq (cc0) (const_int 0)) - (label_ref ...) - (pc)))]) - - But this is incorrect, because it says that the jump condition - depends on the condition code value *before* this instruction, not - on the new value that is set by this instruction. - - Peephole optimization, which takes place together with final - assembly code output, can produce insns whose patterns consist of - a `parallel' whose elements are the operands needed to output the - resulting assembler code--often `reg', `mem' or constant - expressions. This would not be well-formed RTL at any other stage - in compilation, but it is ok then because no further optimization - remains to be done. However, the definition of the macro - `NOTICE_UPDATE_CC', if any, must deal with such insns if you - define any peephole optimizations. - -`(sequence [INSNS ...])' - Represents a sequence of insns. Each of the INSNS that appears in - the vector is suitable for appearing in the chain of insns, so it - must be an `insn', `jump_insn', `call_insn', `code_label', - `barrier' or `note'. - - A `sequence' RTX is never placed in an actual insn during RTL - generation. It represents the sequence of insns that result from a - `define_expand' *before* those insns are passed to `emit_insn' to - insert them in the chain of insns. When actually inserted, the - individual sub-insns are separated out and the `sequence' is - forgotten. - - After delay-slot scheduling is completed, an insn and all the - insns that reside in its delay slots are grouped together into a - `sequence'. The insn requiring the delay slot is the first insn in - the vector; subsequent insns are to be placed in the delay slot. - - `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to - indicate that a branch insn should be used that will conditionally - annul the effect of the insns in the delay slots. In such a case, - `INSN_FROM_TARGET_P' indicates that the insn is from the target of - the branch and should be executed only if the branch is taken; - otherwise the insn should be executed only if the branch is not - taken. *Note Delay Slots::. - - These expression codes appear in place of a side effect, as the body -of an insn, though strictly speaking they do not always describe side -effects as such: - -`(asm_input S)' - Represents literal assembler code as described by the string S. - -`(unspec [OPERANDS ...] INDEX)' -`(unspec_volatile [OPERANDS ...] INDEX)' - Represents a machine-specific operation on OPERANDS. INDEX - selects between multiple machine-specific operations. - `unspec_volatile' is used for volatile operations and operations - that may trap; `unspec' is used for other operations. - - These codes may appear inside a `pattern' of an insn, inside a - `parallel', or inside an expression. - -`(addr_vec:M [LR0 LR1 ...])' - Represents a table of jump addresses. The vector elements LR0, - etc., are `label_ref' expressions. The mode M specifies how much - space is given to each address; normally M would be `Pmode'. - -`(addr_diff_vec:M BASE [LR0 LR1 ...])' - Represents a table of jump addresses expressed as offsets from - BASE. The vector elements LR0, etc., are `label_ref' expressions - and so is BASE. The mode M specifies how much space is given to - each address-difference. + 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. + + This extension is not supported by GNU C++. + + +File: gcc.info, Node: Function Names, Prev: Incomplete Enums, Up: C Extensions + +Function Names as Strings +========================= + + GNU CC predefines two string variables to be the name of the current +function. The variable `__FUNCTION__' is the name of the function as +it appears in the source. The variable `__PRETTY_FUNCTION__' is the +name of the function pretty printed in a language specific fashion. + + These names are always the same in a C function, but in a C++ +function they may be different. For example, this program: + + extern "C" { + extern int printf (char *, ...); + } + + class a { + public: + sub (int i) + { + printf ("__FUNCTION__ = %s\n", __FUNCTION__); + printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__); + } + }; + + int + main (void) + { + a ax; + ax.sub (0); + return 0; + } + +gives this output: + + __FUNCTION__ = sub + __PRETTY_FUNCTION__ = int a::sub (int) + + 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: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL +File: gcc.info, Node: C++ Extensions, Next: Trouble, Prev: C Extensions, Up: Top -Embedded Side-Effects on Addresses -================================== +Extensions to the C++ Language +****************************** - Four special side-effect expression codes appear as memory addresses. + 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.). -`(pre_dec:M X)' - Represents the side effect of decrementing X by a standard amount - and represents also the value that X has after being decremented. - X must be a `reg' or `mem', but most machines allow only a `reg'. - M must be the machine mode for pointers on the machine in use. - The amount X is decremented by is the length in bytes of the - machine mode of the containing memory reference of which this - expression serves as the address. Here is an example of its use: - - (mem:DF (pre_dec:SI (reg:SI 39))) - - This says to decrement pseudo register 39 by the length of a - `DFmode' value and use the result to address a `DFmode' value. - -`(pre_inc:M X)' - Similar, but specifies incrementing X instead of decrementing it. - -`(post_dec:M X)' - Represents the same side effect as `pre_dec' but a different - value. The value represented here is the value X has before being - decremented. - -`(post_inc:M X)' - Similar, but specifies incrementing X instead of decrementing it. - - These embedded side effect expressions must be used with care. -Instruction patterns may not use them. Until the `flow' pass of the -compiler, they may occur only to represent pushes onto the stack. The -`flow' pass finds cases where registers are incremented or decremented -in one instruction and used as an address shortly before or after; -these cases are then transformed to use pre- or post-increment or --decrement. - - If a register used as the operand of these expressions is used in -another address in an insn, the original value of the register is used. -Uses of the register outside of an address are not permitted within the -same insn as a use in an embedded side effect expression because such -insns behave differently on different machines and hence must be treated -as ambiguous and disallowed. - - An instruction that can be represented with an embedded side effect -could also be represented using `parallel' containing an additional -`set' to describe how the address register is altered. This is not -done because machines that allow these operations at all typically -allow them wherever a memory address is called for. Describing them as -additional parallel stores would require doubling the number of entries -in the machine description. +* 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: Assembler, Next: Insns, Prev: IncDec, Up: RTL +File: gcc.info, Node: Naming Results, Next: Min and Max, Up: C++ Extensions -Assembler Instructions as Expressions -===================================== +Named Return Values in C++ +========================== - The RTX code `asm_operands' represents a value produced by a -user-specified assembler instruction. It is used to represent an `asm' -statement with arguments. An `asm' statement with a single output -operand, like this: - - asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); - -is represented using a single `asm_operands' RTX which represents the -value that is stored in `outputvar': - - (set RTX-FOR-OUTPUTVAR - (asm_operands "foo %1,%2,%0" "a" 0 - [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] - [(asm_input:M1 "g") - (asm_input:M2 "di")])) - -Here the operands of the `asm_operands' RTX are the assembler template -string, the output-operand's constraint, the index-number of the output -operand among the output operands specified, a vector of input operand -RTX's, and a vector of input-operand modes and constraints. The mode -M1 is the mode of the sum `x+y'; M2 is that of `*z'. - - When an `asm' statement has multiple output values, its insn has -several such `set' RTX's inside of a `parallel'. Each `set' contains a -`asm_operands'; all of these share the same assembler template and -vectors, but each contains the constraint for the respective output -operand. They are also distinguished by the output-operand index -number, which is 0, 1, ... for successive output operands. + 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; + } + +(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: Insns, Next: Calls, Prev: Assembler, Up: RTL +File: gcc.info, Node: Min and Max, Next: Destructors and Goto, Prev: Naming Results, Up: C++ Extensions + +Minimum and Maximum Operators in C++ +==================================== -Insns -===== + 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), - The RTL representation of the code for a function is a doubly-linked -chain of objects called "insns". Insns are expressions with special -codes that are used for no other purpose. Some insns are actual -instructions; others represent dispatch tables for `switch' statements; -others represent labels to jump to or various sorts of declarative -information. - - In addition to its own specific data, each insn must have a unique -id-number that distinguishes it from all other insns in the current -function (after delayed branch scheduling, copies of an insn with the -same id-number may be present in multiple places in a function, but -these copies will always be identical and will only appear inside a -`sequence'), and chain pointers to the preceding and following insns. -These three fields occupy the same position in every insn, independent -of the expression code of the insn. They could be accessed with `XEXP' -and `XINT', but instead three special macros are always used: - -`INSN_UID (I)' - Accesses the unique id of insn I. - -`PREV_INSN (I)' - Accesses the chain pointer to the insn preceding I. If I is the - first insn, this is a null pointer. - -`NEXT_INSN (I)' - Accesses the chain pointer to the insn following I. If I is the - last insn, this is a null pointer. - - The first insn in the chain is obtained by calling `get_insns'; the -last insn is the result of calling `get_last_insn'. Within the chain -delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must -always correspond: if INSN is not the first insn, - - NEXT_INSN (PREV_INSN (INSN)) == INSN - -is always true and if INSN is not the last insn, - - PREV_INSN (NEXT_INSN (INSN)) == INSN - -is always true. - - After delay slot scheduling, some of the insns in the chain might be -`sequence' expressions, which contain a vector of insns. The value of -`NEXT_INSN' in all but the last of these insns is the next insn in the -vector; the value of `NEXT_INSN' of the last insn in the vector is the -same as the value of `NEXT_INSN' for the `sequence' in which it is -contained. Similar rules apply for `PREV_INSN'. - - This means that the above invariants are not necessarily true for -insns inside `sequence' expressions. Specifically, if INSN is the -first insn in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn -containing the `sequence' expression, as is the value of `PREV_INSN -(NEXT_INSN (INSN))' is INSN is the last insn in the `sequence' -expression. You can use these expressions to find the containing -`sequence' expression. - - Every insn has one of the following six expression codes: - -`insn' - The expression code `insn' is used for instructions that do not - jump and do not do function calls. `sequence' expressions are - always contained in insns with code `insn' even if one of those - insns should jump or do function calls. - - Insns with code `insn' have four additional fields beyond the three - mandatory ones listed above. These four are described in a table - below. - -`jump_insn' - The expression code `jump_insn' is used for instructions that may - jump (or, more generally, may contain `label_ref' expressions). If - there is an instruction to return from the current function, it is - recorded as a `jump_insn'. - - `jump_insn' insns have the same extra fields as `insn' insns, - accessed in the same way and in addition contains a field - `JUMP_LABEL' which is defined once jump optimization has completed. - - For simple conditional and unconditional jumps, this field - contains the `code_label' to which this insn will (possibly - conditionally) branch. In a more complex jump, `JUMP_LABEL' - records one of the labels that the insn refers to; the only way to - find the others is to scan the entire body of the insn. - - Return insns count as jumps, but since they do not refer to any - labels, they have zero in the `JUMP_LABEL' field. - -`call_insn' - The expression code `call_insn' is used for instructions that may - do function calls. It is important to distinguish these - instructions because they imply that certain registers and memory - locations may be altered unpredictably. - - A `call_insn' insn may be preceded by insns that contain a single - `use' expression and be followed by insns the contain a single - `clobber' expression. If so, these `use' and `clobber' - expressions are treated as being part of the function call. There - must not even be a `note' between the `call_insn' and the `use' or - `clobber' insns for this special treatment to take place. This is - somewhat of a kludge and will be removed in a later version of GNU - CC. - - `call_insn' insns have the same extra fields as `insn' insns, - accessed in the same way. - -`code_label' - A `code_label' insn represents a label that a jump insn can jump - to. It contains two special fields of data in addition to the - three standard ones. `CODE_LABEL_NUMBER' is used to hold the - "label number", a number that identifies this label uniquely among - all the labels in the compilation (not just in the current - function). Ultimately, the label is represented in the assembler - output as an assembler label, usually of the form `LN' where N is - the label number. - - When a `code_label' appears in an RTL expression, it normally - appears within a `label_ref' which represents the address of the - label, as a number. - - The field `LABEL_NUSES' is only defined once the jump optimization - phase is completed and contains the number of times this label is - referenced in the current function. - -`barrier' - Barriers are placed in the instruction stream when control cannot - flow past them. They are placed after unconditional jump - instructions to indicate that the jumps are unconditional and - after calls to `volatile' functions, which do not return (e.g., - `exit'). They contain no information beyond the three standard - fields. - -`note' - `note' insns are used to represent additional debugging and - declarative information. They contain two nonstandard fields, an - integer which is accessed with the macro `NOTE_LINE_NUMBER' and a - string accessed with `NOTE_SOURCE_FILE'. - - If `NOTE_LINE_NUMBER' is positive, the note represents the - position of a source line and `NOTE_SOURCE_FILE' is the source - file name that the line came from. These notes control generation - of line number data in the assembler output. - - Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a - code with one of the following values (and `NOTE_SOURCE_FILE' must - contain a null pointer): - - `NOTE_INSN_DELETED' - Such a note is completely ignorable. Some passes of the - compiler delete insns by altering them into notes of this - kind. - - `NOTE_INSN_BLOCK_BEG' - `NOTE_INSN_BLOCK_END' - These types of notes indicate the position of the beginning - and end of a level of scoping of variable names. They - control the output of debugging information. - - `NOTE_INSN_LOOP_BEG' - `NOTE_INSN_LOOP_END' - These types of notes indicate the position of the beginning - and end of a `while' or `for' loop. They enable the loop - optimizer to find loops quickly. - - `NOTE_INSN_LOOP_CONT' - Appears at the place in a loop that `continue' statements - jump to. - - `NOTE_INSN_LOOP_VTOP' - This note indicates the place in a loop where the exit test - begins for those loops in which the exit test has been - duplicated. This position becomes another virtual start of - the loop when considering loop invariants. - - `NOTE_INSN_FUNCTION_END' - Appears near the end of the function body, just before the - label that `return' statements jump to (on machine where a - single instruction does not suffice for returning). This - note may be deleted by jump optimization. - - `NOTE_INSN_SETJMP' - Appears following each call to `setjmp' or a related function. - - These codes are printed symbolically when they appear in debugging - dumps. - - The machine mode of an insn is normally `VOIDmode', but some phases -use the mode for various purposes; for example, the reload pass sets it -to `HImode' if the insn needs reloading but not register elimination -and `QImode' if both are required. The common subexpression -elimination pass sets the mode of an insn to `QImode' when it is the -first insn in a block that has already been processed. - - Here is a table of the extra fields of `insn', `jump_insn' and -`call_insn' insns: - -`PATTERN (I)' - An expression for the side effect performed by this insn. This - must be one of the following codes: `set', `call', `use', - `clobber', `return', `asm_input', `asm_output', `addr_vec', - `addr_diff_vec', `trap_if', `unspec', `unspec_volatile', - `parallel', or `sequence'. If it is a `parallel', each element of - the `parallel' must be one these codes, except that `parallel' - expressions cannot be nested and `addr_vec' and `addr_diff_vec' - are not permitted inside a `parallel' expression. - -`INSN_CODE (I)' - An integer that says which pattern in the machine description - matches this insn, or -1 if the matching has not yet been - attempted. - - Such matching is never attempted and this field remains -1 on an - insn whose pattern consists of a single `use', `clobber', - `asm_input', `addr_vec' or `addr_diff_vec' expression. - - Matching is also never attempted on insns that result from an `asm' - statement. These contain at least one `asm_operands' expression. - The function `asm_noperands' returns a non-negative value for such - insns. - - In the debugging output, this field is printed as a number - followed by a symbolic representation that locates the pattern in - the `md' file as some small positive or negative offset from a - named pattern. - -`LOG_LINKS (I)' - A list (chain of `insn_list' expressions) giving information about - dependencies between instructions within a basic block. Neither a - jump nor a label may come between the related insns. - -`REG_NOTES (I)' - A list (chain of `expr_list' and `insn_list' expressions) giving - miscellaneous information about the insn. It is often information - pertaining to the registers used in this insn. - - The `LOG_LINKS' field of an insn is a chain of `insn_list' -expressions. Each of these has two operands: the first is an insn, and -the second is another `insn_list' expression (the next one in the -chain). The last `insn_list' in the chain has a null pointer as second -operand. The significant thing about the chain is which insns appear -in it (as first operands of `insn_list' expressions). Their order is -not significant. - - This list is originally set up by the flow analysis pass; it is a -null pointer until then. Flow only adds links for those data -dependencies which can be used for instruction combination. For each -insn, the flow analysis pass adds a link to insns which store into -registers values that are used for the first time in this insn. The -instruction scheduling pass adds extra links so that every dependence -will be represented. Links represent data dependencies, -antidependencies and output dependencies; the machine mode of the link -distinguishes these three types: antidependencies have mode -`REG_DEP_ANTI', output dependencies have mode `REG_DEP_OUTPUT', and -data dependencies have mode `VOIDmode'. - - The `REG_NOTES' field of an insn is a chain similar to the -`LOG_LINKS' field but it includes `expr_list' expressions in addition -to `insn_list' expressions. There are several kinds of register notes, -which are distinguished by the machine mode, which in a register note -is really understood as being an `enum reg_note'. The first operand OP -of the note is data whose meaning depends on the kind of note. - - The macro `REG_NOTE_KIND (X)' returns the kind of register note. -Its counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the -register note type of X to be NEWKIND. - - Register notes are of three classes: They may say something about an -input to an insn, they may say something about an output of an insn, or -they may create a linkage between two insns. There are also a set of -values that are only used in `LOG_LINKS'. - - These register notes annotate inputs to an insn: - -`REG_DEAD' - The value in OP dies in this insn; that is to say, altering the - value immediately after this insn would not affect the future - behavior of the program. - - This does not necessarily mean that the register OP has no useful - value after this insn since it may also be an output of the insn. - In such a case, however, a `REG_DEAD' note would be redundant and - is usually not present until after the reload pass, but no code - relies on this fact. - -`REG_INC' - The register OP is incremented (or decremented; at this level - there is no distinction) by an embedded side effect inside this - insn. This means it appears in a `post_inc', `pre_inc', `post_dec' - or `pre_dec' expression. - -`REG_NONNEG' - The register OP is known to have a nonnegative value when this - insn is reached. This is used so that decrement and branch until - zero instructions, such as the m68k dbra, can be matched. - - The `REG_NONNEG' note is added to insns only if the machine - description contains a pattern named - `decrement_and_branch_until_zero'. - -`REG_NO_CONFLICT' - This insn does not cause a conflict between OP and the item being - set by this insn even though it might appear that it does. In - other words, if the destination register and OP could otherwise be - assigned the same register, this insn does not prevent that - assignment. - - Insns with this note are usually part of a block that begins with a - `clobber' insn specifying a multi-word pseudo register (which will - be the output of the block), a group of insns that each set one - word of the value and have the `REG_NO_CONFLICT' note attached, - and a final insn that copies the output to itself with an attached - `REG_EQUAL' note giving the expression being computed. This block - is encapsulated with `REG_LIBCALL' and `REG_RETVAL' notes on the - first and last insns, respectively. - -`REG_LABEL' - This insn uses OP, a `code_label', but is not a `jump_insn'. The - presence of this note allows jump optimization to be aware that OP - is, in fact, being used. - - The following notes describe attributes of outputs of an insn: - -`REG_EQUIV' -`REG_EQUAL' - This note is only valid on an insn that sets only one register and - indicates that that register will be equal to OP at run time; the - scope of this equivalence differs between the two types of notes. - The value which the insn explicitly copies into the register may - look different from OP, but they will be equal at run time. If the - output of the single `set' is a `strict_low_part' expression, the - note refers to the register that is contained in `SUBREG_REG' of - the `subreg' expression. - - For `REG_EQUIV', the register is equivalent to OP throughout the - entire function, and could validly be replaced in all its - occurrences by OP. ("Validly" here refers to the data flow of the - program; simple replacement may make some insns invalid.) For - example, when a constant is loaded into a register that is never - assigned any other value, this kind of note is used. - - When a parameter is copied into a pseudo-register at entry to a - function, a note of this kind records that the register is - equivalent to the stack slot where the parameter was passed. - Although in this case the register may be set by other insns, it - is still valid to replace the register by the stack slot - throughout the function. - - In the case of `REG_EQUAL', the register that is set by this insn - will be equal to OP at run time at the end of this insn but not - necessarily elsewhere in the function. In this case, OP is - typically an arithmetic expression. For example, when a sequence - of insns such as a library call is used to perform an arithmetic - operation, this kind of note is attached to the insn that produces - or copies the final value. - - These two notes are used in different ways by the compiler passes. - `REG_EQUAL' is used by passes prior to register allocation (such as - common subexpression elimination and loop optimization) to tell - them how to think of that value. `REG_EQUIV' notes are used by - register allocation to indicate that there is an available - substitute expression (either a constant or a `mem' expression for - the location of a parameter on the stack) that may be used in - place of a register if insufficient registers are available. - - Except for stack homes for parameters, which are indicated by a - `REG_EQUIV' note and are not useful to the early optimization - passes and pseudo registers that are equivalent to a memory - location throughout there entire life, which is not detected until - later in the compilation, all equivalences are initially indicated - by an attached `REG_EQUAL' note. In the early stages of register - allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note - if OP is a constant and the insn represents the only set of its - destination register. - - Thus, compiler passes prior to register allocation need only check - for `REG_EQUAL' notes and passes subsequent to register allocation - need only check for `REG_EQUIV' notes. - -`REG_UNUSED' - The register OP being set by this insn will not be used in a - subsequent insn. This differs from a `REG_DEAD' note, which - indicates that the value in an input will not be used subsequently. - These two notes are independent; both may be present for the same - register. - -`REG_WAS_0' - The single output of this insn contained zero before this insn. OP - is the insn that set it to zero. You can rely on this note if it - is present and OP has not been deleted or turned into a `note'; - its absence implies nothing. - - These notes describe linkages between insns. They occur in pairs: -one insn has one of a pair of notes that points to a second insn, which -has the inverse note pointing back to the first insn. - -`REG_RETVAL' - This insn copies the value of a multi-insn sequence (for example, a - library call), and OP is the first insn of the sequence (for a - library call, the first insn that was generated to set up the - arguments for the library call). - - Loop optimization uses this note to treat such a sequence as a - single operation for code motion purposes and flow analysis uses - this note to delete such sequences whose results are dead. - - A `REG_EQUAL' note will also usually be attached to this insn to - provide the expression being computed by the sequence. - -`REG_LIBCALL' - This is the inverse of `REG_RETVAL': it is placed on the first - insn of a multi-insn sequence, and it points to the last one. - -`REG_CC_SETTER' -`REG_CC_USER' - On machines that use `cc0', the insns which set and use `cc0' set - and use `cc0' are adjacent. However, when branch delay slot - filling is done, this may no longer be true. In this case a - `REG_CC_USER' note will be placed on the insn setting `cc0' to - point to the insn using `cc0' and a `REG_CC_SETTER' note will be - placed on the insn using `cc0' to point to the insn setting `cc0'. - - These values are only used in the `LOG_LINKS' field, and indicate -the type of dependency that each link represents. Links which indicate -a data dependence (a read after write dependence) do not use any code, -they simply have mode `VOIDmode', and are printed without any -descriptive text. - -`REG_DEP_ANTI' - This indicates an anti dependence (a write after read dependence). - -`REG_DEP_OUTPUT' - This indicates an output dependence (a write after write - dependence). - - For convenience, the machine mode in an `insn_list' or `expr_list' -is printed using these symbolic codes in debugging dumps. - - The only difference between the expression codes `insn_list' and -`expr_list' is that the first operand of an `insn_list' is assumed to -be an insn and is printed in debugging dumps as the insn's unique id; -the first operand of an `expr_list' is printed in the ordinary way as -an expression. +`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. - The `.md' file for a target machine contains a pattern for each -instruction that the target machine supports (or at least each -instruction that is worth telling the compiler about). It may also -contain comments. A semicolon causes the rest of the line to be a -comment, unless the semicolon is inside a quoted string. + +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 + { + 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 - See the next chapter for information on the C header file. +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: -* Patterns:: How to write instruction patterns. -* Example:: An explained example of a `define_insn' pattern. -* RTL Template:: The RTL template defines what insns match a pattern. -* Output Template:: The output template says how to make assembler code - from such an insn. -* Output Statement:: For more generality, write C code to output - the assembler code. -* Constraints:: When not all operands are general operands. -* Standard Names:: Names mark patterns to use for code generation. -* Pattern Ordering:: When the order of patterns makes a difference. -* Dependent Patterns:: Having one pattern may make you need another. -* Jump Patterns:: Special considerations for patterns for jump insns. -* Insn Canonicalizations::Canonicalization of Instructions -* Peephole Definitions::Defining machine-specific peephole optimizations. -* Expander Definitions::Generating a sequence of several RTL insns - for a standard operation. -* Insn Splitting:: Splitting Instructions into Multiple Instructions -* Insn Attributes:: Specifying the value of attributes for generated insns. +* 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