mirror of
https://github.com/pmret/gcc-papermario.git
synced 2024-11-09 12:22:38 +01:00
898 lines
36 KiB
Plaintext
898 lines
36 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo version 1.67 from the
|
||
input file gcc.texi.
|
||
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Published by the Free Software Foundation 59 Temple Place - Suite 330
|
||
Boston, MA 02111-1307 USA
|
||
|
||
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998
|
||
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 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," "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: DEC Alpha Options, Next: Clipper Options, Prev: Intel 960 Options, Up: Submodel Options
|
||
|
||
DEC Alpha Options
|
||
-----------------
|
||
|
||
These `-m' options are defined for the DEC Alpha implementations:
|
||
|
||
`-mno-soft-float'
|
||
`-msoft-float'
|
||
Use (do not use) the hardware floating-point instructions for
|
||
floating-point operations. When `-msoft-float' is specified,
|
||
functions in `libgcc1.c' will be used to perform floating-point
|
||
operations. Unless they are replaced by routines that emulate the
|
||
floating-point operations, or compiled in such a way as to call
|
||
such emulations routines, these routines will issue floating-point
|
||
operations. If you are compiling for an Alpha without
|
||
floating-point operations, you must ensure that the library is
|
||
built so as not to call them.
|
||
|
||
Note that Alpha implementations without floating-point operations
|
||
are required to have floating-point registers.
|
||
|
||
`-mfp-reg'
|
||
`-mno-fp-regs'
|
||
Generate code that uses (does not use) the floating-point register
|
||
set. `-mno-fp-regs' implies `-msoft-float'. If the floating-point
|
||
register set is not used, floating point operands are passed in
|
||
integer registers as if they were integers and floating-point
|
||
results are passed in $0 instead of $f0. This is a non-standard
|
||
calling sequence, so any function with a floating-point argument
|
||
or return value called by code compiled with `-mno-fp-regs' must
|
||
also be compiled with that option.
|
||
|
||
A typical use of this option is building a kernel that does not
|
||
use, and hence need not save and restore, any floating-point
|
||
registers.
|
||
|
||
`-mieee'
|
||
The Alpha architecture implements floating-point hardware
|
||
optimized for maximum performance. It is mostly compliant with
|
||
the IEEE floating point standard. However, for full compliance,
|
||
software assistance is required. This option generates code fully
|
||
IEEE compliant code *except* that the INEXACT FLAG is not
|
||
maintained (see below). If this option is turned on, the CPP
|
||
macro `_IEEE_FP' is defined during compilation. The option is a
|
||
shorthand for: `-D_IEEE_FP -mfp-trap-mode=su -mtrap-precision=i
|
||
-mieee-conformant'. The resulting code is less efficient but is
|
||
able to correctly support denormalized numbers and exceptional
|
||
IEEE values such as not-a-number and plus/minus infinity. Other
|
||
Alpha compilers call this option `-ieee_with_no_inexact'.
|
||
|
||
`-mieee-with-inexact'
|
||
This is like `-mieee' except the generated code also maintains the
|
||
IEEE INEXACT FLAG. Turning on this option causes the generated
|
||
code to implement fully-compliant IEEE math. The option is a
|
||
shorthand for `-D_IEEE_FP -D_IEEE_FP_INEXACT' plus the three
|
||
following: `-mieee-conformant', `-mfp-trap-mode=sui', and
|
||
`-mtrap-precision=i'. On some Alpha implementations the resulting
|
||
code may execute significantly slower than the code generated by
|
||
default. Since there is very little code that depends on the
|
||
INEXACT FLAG, you should normally not specify this option. Other
|
||
Alpha compilers call this option `-ieee_with_inexact'.
|
||
|
||
`-mfp-trap-mode=TRAP MODE'
|
||
This option controls what floating-point related traps are enabled.
|
||
Other Alpha compilers call this option `-fptm 'TRAP MODE. The
|
||
trap mode can be set to one of four values:
|
||
|
||
`n'
|
||
This is the default (normal) setting. The only traps that
|
||
are enabled are the ones that cannot be disabled in software
|
||
(e.g., division by zero trap).
|
||
|
||
`u'
|
||
In addition to the traps enabled by `n', underflow traps are
|
||
enabled as well.
|
||
|
||
`su'
|
||
Like `su', but the instructions are marked to be safe for
|
||
software completion (see Alpha architecture manual for
|
||
details).
|
||
|
||
`sui'
|
||
Like `su', but inexact traps are enabled as well.
|
||
|
||
`-mfp-rounding-mode=ROUNDING MODE'
|
||
Selects the IEEE rounding mode. Other Alpha compilers call this
|
||
option `-fprm 'ROUNDING MODE. The ROUNDING MODE can be one of:
|
||
|
||
`n'
|
||
Normal IEEE rounding mode. Floating point numbers are
|
||
rounded towards the nearest machine number or towards the
|
||
even machine number in case of a tie.
|
||
|
||
`m'
|
||
Round towards minus infinity.
|
||
|
||
`c'
|
||
Chopped rounding mode. Floating point numbers are rounded
|
||
towards zero.
|
||
|
||
`d'
|
||
Dynamic rounding mode. A field in the floating point control
|
||
register (FPCR, see Alpha architecture reference manual)
|
||
controls the rounding mode in effect. The C library
|
||
initializes this register for rounding towards plus infinity.
|
||
Thus, unless your program modifies the FPCR, `d' corresponds
|
||
to round towards plus infinity.
|
||
|
||
`-mtrap-precision=TRAP PRECISION'
|
||
In the Alpha architecture, floating point traps are imprecise.
|
||
This means without software assistance it is impossible to recover
|
||
from a floating trap and program execution normally needs to be
|
||
terminated. GNU CC can generate code that can assist operating
|
||
system trap handlers in determining the exact location that caused
|
||
a floating point trap. Depending on the requirements of an
|
||
application, different levels of precisions can be selected:
|
||
|
||
`p'
|
||
Program precision. This option is the default and means a
|
||
trap handler can only identify which program caused a
|
||
floating point exception.
|
||
|
||
`f'
|
||
Function precision. The trap handler can determine the
|
||
function that caused a floating point exception.
|
||
|
||
`i'
|
||
Instruction precision. The trap handler can determine the
|
||
exact instruction that caused a floating point exception.
|
||
|
||
Other Alpha compilers provide the equivalent options called
|
||
`-scope_safe' and `-resumption_safe'.
|
||
|
||
`-mieee-conformant'
|
||
This option marks the generated code as IEEE conformant. You must
|
||
not use this option unless you also specify `-mtrap-precision=i'
|
||
and either `-mfp-trap-mode=su' or `-mfp-trap-mode=sui'. Its only
|
||
effect is to emit the line `.eflag 48' in the function prologue of
|
||
the generated assembly file. Under DEC Unix, this has the effect
|
||
that IEEE-conformant math library routines will be linked in.
|
||
|
||
`-mbuild-constants'
|
||
Normally GNU CC examines a 32- or 64-bit integer constant to see
|
||
if it can construct it from smaller constants in two or three
|
||
instructions. If it cannot, it will output the constant as a
|
||
literal and generate code to load it from the data segment at
|
||
runtime.
|
||
|
||
Use this option to require GNU CC to construct *all* integer
|
||
constants using code, even if it takes more instructions (the
|
||
maximum is six).
|
||
|
||
You would typically use this option to build a shared library
|
||
dynamic loader. Itself a shared library, it must relocate itself
|
||
in memory before it can find the variables and constants in its
|
||
own data segment.
|
||
|
||
`-malpha-as'
|
||
`-mgas'
|
||
Select whether to generate code to be assembled by the
|
||
vendor-supplied assembler (`-malpha-as') or by the GNU assembler
|
||
`-mgas'.
|
||
|
||
`-mbwx'
|
||
`-mno-bwx'
|
||
`-mcix'
|
||
`-mno-cix'
|
||
`-mmax'
|
||
`-mno-max'
|
||
Indicate whether GNU CC should generate code to use the optional
|
||
BWX, CIX, and MAX instruction sets. The default is to use the
|
||
instruction sets supported by the CPU type specified via `-mcpu='
|
||
option or that of the CPU on which GNU CC was built if none was
|
||
specified.
|
||
|
||
`-mcpu=CPU_TYPE'
|
||
Set the instruction set, register set, and instruction scheduling
|
||
parameters for machine type CPU_TYPE. You can specify either the
|
||
`EV' style name or the corresponding chip number. GNU CC supports
|
||
scheduling parameters for the EV4 and EV5 family of processors and
|
||
will choose the default values for the instruction set from the
|
||
processor you specify. If you do not specify a processor type,
|
||
GNU CC will default to the processor on which the compiler was
|
||
built.
|
||
|
||
Supported values for CPU_TYPE are
|
||
|
||
`ev4'
|
||
`21064'
|
||
Schedules as an EV4 and has no instruction set extensions.
|
||
|
||
`ev5'
|
||
`21164'
|
||
Schedules as an EV5 and has no instruction set extensions.
|
||
|
||
`ev56'
|
||
`21164a'
|
||
Schedules as an EV5 and supports the BWX extension.
|
||
|
||
`pca56'
|
||
`21164PC'
|
||
Schedules as an EV5 and supports the BWX and MAX extensions.
|
||
|
||
`ev6'
|
||
`21264'
|
||
Schedules as an EV5 (until Digital releases the scheduling
|
||
parameters for the EV6) and supports the BWX, CIX, and MAX
|
||
extensions.
|
||
|
||
|
||
File: gcc.info, Node: Clipper Options, Next: H8/300 Options, Prev: DEC Alpha Options, Up: Submodel Options
|
||
|
||
Clipper Options
|
||
---------------
|
||
|
||
These `-m' options are defined for the Clipper implementations:
|
||
|
||
`-mc300'
|
||
Produce code for a C300 Clipper processor. This is the default.
|
||
|
||
`-mc400'
|
||
Produce code for a C400 Clipper processor i.e. use floating point
|
||
registers f8..f15.
|
||
|
||
|
||
File: gcc.info, Node: H8/300 Options, Next: SH Options, Prev: Clipper Options, Up: Submodel Options
|
||
|
||
H8/300 Options
|
||
--------------
|
||
|
||
These `-m' options are defined for the H8/300 implementations:
|
||
|
||
`-mrelax'
|
||
Shorten some address references at link time, when possible; uses
|
||
the linker option `-relax'. *Note `ld' and the H8/300:
|
||
(ld.info)H8/300, for a fuller description.
|
||
|
||
`-mh'
|
||
Generate code for the H8/300H.
|
||
|
||
`-ms'
|
||
Generate code for the H8/S.
|
||
|
||
`-mint32'
|
||
Make `int' data 32 bits by default.
|
||
|
||
`-malign-300'
|
||
On the h8/300h, use the same alignment rules as for the h8/300.
|
||
The default for the h8/300h is to align longs and floats on 4 byte
|
||
boundaries. `-malign-300' causes them to be aligned on 2 byte
|
||
boundaries. This option has no effect on the h8/300.
|
||
|
||
|
||
File: gcc.info, Node: SH Options, Next: System V Options, Prev: H8/300 Options, Up: Submodel Options
|
||
|
||
SH Options
|
||
----------
|
||
|
||
These `-m' options are defined for the SH implementations:
|
||
|
||
`-m1'
|
||
Generate code for the SH1.
|
||
|
||
`-m2'
|
||
Generate code for the SH2.
|
||
|
||
`-m3'
|
||
Generate code for the SH3.
|
||
|
||
`-m3e'
|
||
Generate code for the SH3e.
|
||
|
||
`-mb'
|
||
Compile code for the processor in big endian mode.
|
||
|
||
`-ml'
|
||
Compile code for the processor in little endian mode.
|
||
|
||
`-mrelax'
|
||
Shorten some address references at link time, when possible; uses
|
||
the linker option `-relax'.
|
||
|
||
|
||
File: gcc.info, Node: System V Options, Next: V850 Options, Prev: SH Options, Up: Submodel Options
|
||
|
||
Options for System V
|
||
--------------------
|
||
|
||
These additional options are available on System V Release 4 for
|
||
compatibility with other compilers on those systems:
|
||
|
||
`-G'
|
||
Create a shared object. It is recommended that `-symbolic' or
|
||
`-shared' be used instead.
|
||
|
||
`-Qy'
|
||
Identify the versions of each tool used by the compiler, in a
|
||
`.ident' assembler directive in the output.
|
||
|
||
`-Qn'
|
||
Refrain from adding `.ident' directives to the output file (this is
|
||
the default).
|
||
|
||
`-YP,DIRS'
|
||
Search the directories DIRS, and no others, for libraries
|
||
specified with `-l'.
|
||
|
||
`-Ym,DIR'
|
||
Look in the directory DIR to find the M4 preprocessor. The
|
||
assembler uses this option.
|
||
|
||
|
||
File: gcc.info, Node: V850 Options, Prev: System V Options, Up: Submodel Options
|
||
|
||
V850 Options
|
||
------------
|
||
|
||
These `-m' options are defined for V850 implementations:
|
||
|
||
`-mlong-calls'
|
||
`-mno-long-calls'
|
||
Treat all calls as being far away (near). If calls are assumed to
|
||
be far away, the compiler will always load the functions address
|
||
up into a register, and call indirect through the pointer.
|
||
|
||
`-mno-ep'
|
||
`-mep'
|
||
Do not optimize (do optimize) basic blocks that use the same index
|
||
pointer 4 or more times to copy pointer into the `ep' register, and
|
||
use the shorter `sld' and `sst' instructions. The `-mep' option
|
||
is on by default if you optimize.
|
||
|
||
`-mno-prolog-function'
|
||
`-mprolog-function'
|
||
Do not use (do use) external functions to save and restore
|
||
registers at the prolog and epilog of a function. The external
|
||
functions are slower, but use less code space if more than one
|
||
function saves the same number of registers. The
|
||
`-mprolog-function' option is on by default if you optimize.
|
||
|
||
`-mspace'
|
||
Try to make the code as small as possible. At present, this just
|
||
turns on the `-mep' and `-mprolog-function' options.
|
||
|
||
`-mtda=N'
|
||
Put static or global variables whose size is N bytes or less into
|
||
the tiny data area that register `ep' points to. The tiny data
|
||
area can hold up to 256 bytes in total (128 bytes for byte
|
||
references).
|
||
|
||
`-msda=N'
|
||
Put static or global variables whose size is N bytes or less into
|
||
the small data area that register `gp' points to. The small data
|
||
area can hold up to 64 kilobytes.
|
||
|
||
`-mzda=N'
|
||
Put static or global variables whose size is N bytes or less into
|
||
the first 32 kilobytes of memory.
|
||
|
||
`-mv850'
|
||
Specify that the target processor is the V850.
|
||
|
||
`-mbig-switch'
|
||
Generate code suitable for big switch tables. Use this option
|
||
only if the assembler/linker complain about out of range branches
|
||
within a switch table.
|
||
|
||
|
||
File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC
|
||
|
||
Options for Code Generation Conventions
|
||
=======================================
|
||
|
||
These machine-independent options control the interface conventions
|
||
used in code generation.
|
||
|
||
Most of them have both positive and negative forms; the negative form
|
||
of `-ffoo' would be `-fno-foo'. In the table below, only one of the
|
||
forms is listed--the one which is not the default. You can figure out
|
||
the other form by either removing `no-' or adding it.
|
||
|
||
`-fexceptions'
|
||
Enable exception handling, and generate extra code needed to
|
||
propagate exceptions. If you do not specify this option, GNU CC
|
||
enables it by default for languages like C++ that normally require
|
||
exception handling, and disabled for languages like C that do not
|
||
normally require it. However, when compiling C code that needs to
|
||
interoperate properly with exception handlers written in C++, you
|
||
may need to enable this option. You may also wish to disable this
|
||
option is you are compiling older C++ programs that don't use
|
||
exception handling.
|
||
|
||
`-fpcc-struct-return'
|
||
Return "short" `struct' and `union' values in memory like longer
|
||
ones, rather than in registers. This convention is less
|
||
efficient, but it has the advantage of allowing intercallability
|
||
between GNU CC-compiled files and files compiled with other
|
||
compilers.
|
||
|
||
The precise convention for returning structures in memory depends
|
||
on the target configuration macros.
|
||
|
||
Short structures and unions are those whose size and alignment
|
||
match that of some integer type.
|
||
|
||
`-freg-struct-return'
|
||
Use the convention that `struct' and `union' values are returned
|
||
in registers when possible. This is more efficient for small
|
||
structures than `-fpcc-struct-return'.
|
||
|
||
If you specify neither `-fpcc-struct-return' nor its contrary
|
||
`-freg-struct-return', GNU CC defaults to whichever convention is
|
||
standard for the target. If there is no standard convention, GNU
|
||
CC defaults to `-fpcc-struct-return', except on targets where GNU
|
||
CC is the principal compiler. In those cases, we can choose the
|
||
standard, and we chose the more efficient register return
|
||
alternative.
|
||
|
||
`-fshort-enums'
|
||
Allocate to an `enum' type only as many bytes as it needs for the
|
||
declared range of possible values. Specifically, the `enum' type
|
||
will be equivalent to the smallest integer type which has enough
|
||
room.
|
||
|
||
`-fshort-double'
|
||
Use the same size for `double' as for `float'.
|
||
|
||
`-fshared-data'
|
||
Requests that the data and non-`const' variables of this
|
||
compilation be shared data rather than private data. The
|
||
distinction makes sense only on certain operating systems, where
|
||
shared data is shared between processes running the same program,
|
||
while private data exists in one copy per process.
|
||
|
||
`-fno-common'
|
||
Allocate even uninitialized global variables in the bss section of
|
||
the object file, rather than generating them as common blocks.
|
||
This has the effect that if the same variable is declared (without
|
||
`extern') in two different compilations, you will get an error
|
||
when you link them. The only reason this might be useful is if
|
||
you wish to verify that the program will work on other systems
|
||
which always work this way.
|
||
|
||
`-fno-ident'
|
||
Ignore the `#ident' directive.
|
||
|
||
`-fno-gnu-linker'
|
||
Do not output global initializations (such as C++ constructors and
|
||
destructors) in the form used by the GNU linker (on systems where
|
||
the GNU linker is the standard method of handling them). Use this
|
||
option when you want to use a non-GNU linker, which also requires
|
||
using the `collect2' program to make sure the system linker
|
||
includes constructors and destructors. (`collect2' is included in
|
||
the GNU CC distribution.) For systems which *must* use
|
||
`collect2', the compiler driver `gcc' is configured to do this
|
||
automatically.
|
||
|
||
`-finhibit-size-directive'
|
||
Don't output a `.size' assembler directive, or anything else that
|
||
would cause trouble if the function is split in the middle, and the
|
||
two halves are placed at locations far apart in memory. This
|
||
option is used when compiling `crtstuff.c'; you should not need to
|
||
use it for anything else.
|
||
|
||
`-fverbose-asm'
|
||
Put extra commentary information in the generated assembly code to
|
||
make it more readable. This option is generally only of use to
|
||
those who actually need to read the generated assembly code
|
||
(perhaps while debugging the compiler itself).
|
||
|
||
`-fno-verbose-asm', the default, causes the extra information to
|
||
be omitted and is useful when comparing two assembler files.
|
||
|
||
`-fvolatile'
|
||
Consider all memory references through pointers to be volatile.
|
||
|
||
`-fvolatile-global'
|
||
Consider all memory references to extern and global data items to
|
||
be volatile.
|
||
|
||
`-fpic'
|
||
Generate position-independent code (PIC) suitable for use in a
|
||
shared library, if supported for the target machine. Such code
|
||
accesses all constant addresses through a global offset table
|
||
(GOT). The dynamic loader resolves the GOT entries when the
|
||
program starts (the dynamic loader is not part of GNU CC; it is
|
||
part of the operating system). If the GOT size for the linked
|
||
executable exceeds a machine-specific maximum size, you get an
|
||
error message from the linker indicating that `-fpic' does not
|
||
work; in that case, recompile with `-fPIC' instead. (These
|
||
maximums are 16k on the m88k, 8k on the Sparc, and 32k on the m68k
|
||
and RS/6000. The 386 has no such limit.)
|
||
|
||
Position-independent code requires special support, and therefore
|
||
works only on certain machines. For the 386, GNU CC supports PIC
|
||
for System V but not for the Sun 386i. Code generated for the IBM
|
||
RS/6000 is always position-independent.
|
||
|
||
`-fPIC'
|
||
If supported for the target machine, emit position-independent
|
||
code, suitable for dynamic linking and avoiding any limit on the
|
||
size of the global offset table. This option makes a difference
|
||
on the m68k, m88k, and the Sparc.
|
||
|
||
Position-independent code requires special support, and therefore
|
||
works only on certain machines.
|
||
|
||
`-ffixed-REG'
|
||
Treat the register named REG as a fixed register; generated code
|
||
should never refer to it (except perhaps as a stack pointer, frame
|
||
pointer or in some other fixed role).
|
||
|
||
REG must be the name of a register. The register names accepted
|
||
are machine-specific and are defined in the `REGISTER_NAMES' macro
|
||
in the machine description macro file.
|
||
|
||
This flag does not have a negative form, because it specifies a
|
||
three-way choice.
|
||
|
||
`-fcall-used-REG'
|
||
Treat the register named REG as an allocable register that is
|
||
clobbered by function calls. It may be allocated for temporaries
|
||
or variables that do not live across a call. Functions compiled
|
||
this way will not save and restore the register REG.
|
||
|
||
Use of this flag for a register that has a fixed pervasive role in
|
||
the machine's execution model, such as the stack pointer or frame
|
||
pointer, will produce disastrous results.
|
||
|
||
This flag does not have a negative form, because it specifies a
|
||
three-way choice.
|
||
|
||
`-fcall-saved-REG'
|
||
Treat the register named REG as an allocable register saved by
|
||
functions. It may be allocated even for temporaries or variables
|
||
that live across a call. Functions compiled this way will save
|
||
and restore the register REG if they use it.
|
||
|
||
Use of this flag for a register that has a fixed pervasive role in
|
||
the machine's execution model, such as the stack pointer or frame
|
||
pointer, will produce disastrous results.
|
||
|
||
A different sort of disaster will result from the use of this flag
|
||
for a register in which function values may be returned.
|
||
|
||
This flag does not have a negative form, because it specifies a
|
||
three-way choice.
|
||
|
||
`-fpack-struct'
|
||
Pack all structure members together without holes. Usually you
|
||
would not want to use this option, since it makes the code
|
||
suboptimal, and the offsets of structure members won't agree with
|
||
system libraries.
|
||
|
||
`-fcheck-memory-usage'
|
||
Generate extra code to check each memory access. GNU CC will
|
||
generate code that is suitable for a detector of bad memory
|
||
accesses such as `Checker'. If you specify this option, you can
|
||
not use the `asm' or `__asm__' keywords.
|
||
|
||
You must also specify this option when you compile functions you
|
||
call that have side effects. If you do not, you may get erroneous
|
||
messages from the detector. Normally, you should compile all
|
||
your code with this option. If you use functions from a library
|
||
that have side-effects (such as `read'), you may not be able to
|
||
recompile the library and specify this option. In that case, you
|
||
can enable the `-fprefix-function-name' option, which requests GNU
|
||
CC to encapsulate your code and make other functions look as if
|
||
they were compiled with `-fcheck-memory-usage'. This is done by
|
||
calling "stubs", which are provided by the detector. If you
|
||
cannot find or build stubs for every function you call, you may
|
||
have to specify `-fcheck-memory-usage' without
|
||
`-fprefix-function-name'.
|
||
|
||
`-fprefix-function-name'
|
||
Request GNU CC to add a prefix to the symbols generated for
|
||
function names. GNU CC adds a prefix to the names of functions
|
||
defined as well as functions called. Code compiled with this
|
||
option and code compiled without the option can't be linked
|
||
together, unless or stubs are used.
|
||
|
||
If you compile the following code with `-fprefix-function-name'
|
||
extern void bar (int);
|
||
void
|
||
foo (int a)
|
||
{
|
||
return bar (a + 5);
|
||
|
||
}
|
||
|
||
GNU CC will compile the code as if it was written:
|
||
extern void prefix_bar (int);
|
||
void
|
||
prefix_foo (int a)
|
||
{
|
||
return prefix_bar (a + 5);
|
||
}
|
||
This option is designed to be used with `-fcheck-memory-usage'.
|
||
|
||
`-fstack-check'
|
||
Generate code to verify that you do not go beyond the boundary of
|
||
the stack. You should specify this flag if you are running in an
|
||
environment with multiple threads, but only rarely need to specify
|
||
it in a single-threaded environment since stack overflow is
|
||
automatically detected on nearly all systems if there is only one
|
||
stack.
|
||
|
||
`+e0'
|
||
`+e1'
|
||
Control whether virtual function definitions in classes are used to
|
||
generate code, or only to define interfaces for their callers.
|
||
(C++ only).
|
||
|
||
These options are provided for compatibility with `cfront' 1.x
|
||
usage; the recommended alternative GNU C++ usage is in flux.
|
||
*Note Declarations and Definitions in One Header: C++ Interface.
|
||
|
||
With `+e0', virtual function definitions in classes are declared
|
||
`extern'; the declaration is used only as an interface
|
||
specification, not to generate code for the virtual functions (in
|
||
this compilation).
|
||
|
||
With `+e1', G++ actually generates the code implementing virtual
|
||
functions defined in the code, and makes them publicly visible.
|
||
|
||
|
||
File: gcc.info, Node: Environment Variables, Next: Running Protoize, Prev: Code Gen Options, Up: Invoking GCC
|
||
|
||
Environment Variables Affecting GNU CC
|
||
======================================
|
||
|
||
This section describes several environment variables that affect how
|
||
GNU CC operates. They work by specifying directories or prefixes to use
|
||
when searching for various kinds of files.
|
||
|
||
Note that you can also specify places to search using options such as
|
||
`-B', `-I' and `-L' (*note Directory Options::.). These take
|
||
precedence over places specified using environment variables, which in
|
||
turn take precedence over those specified by the configuration of GNU
|
||
CC. *Note Driver::.
|
||
|
||
`TMPDIR'
|
||
If `TMPDIR' is set, it specifies the directory to use for temporary
|
||
files. GNU CC uses temporary files to hold the output of one
|
||
stage of compilation which is to be used as input to the next
|
||
stage: for example, the output of the preprocessor, which is the
|
||
input to the compiler proper.
|
||
|
||
`GCC_EXEC_PREFIX'
|
||
If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
|
||
names of the subprograms executed by the compiler. No slash is
|
||
added when this prefix is combined with the name of a subprogram,
|
||
but you can specify a prefix that ends with a slash if you wish.
|
||
|
||
If GNU CC cannot find the subprogram using the specified prefix, it
|
||
tries looking in the usual places for the subprogram.
|
||
|
||
The default value of `GCC_EXEC_PREFIX' is `PREFIX/lib/gcc-lib/'
|
||
where PREFIX is the value of `prefix' when you ran the `configure'
|
||
script.
|
||
|
||
Other prefixes specified with `-B' take precedence over this
|
||
prefix.
|
||
|
||
This prefix is also used for finding files such as `crt0.o' that
|
||
are used for linking.
|
||
|
||
In addition, the prefix is used in an unusual way in finding the
|
||
directories to search for header files. For each of the standard
|
||
directories whose name normally begins with
|
||
`/usr/local/lib/gcc-lib' (more precisely, with the value of
|
||
`GCC_INCLUDE_DIR'), GNU CC tries replacing that beginning with the
|
||
specified prefix to produce an alternate directory name. Thus,
|
||
with `-Bfoo/', GNU CC will search `foo/bar' where it would
|
||
normally search `/usr/local/lib/bar'. These alternate directories
|
||
are searched first; the standard directories come next.
|
||
|
||
`COMPILER_PATH'
|
||
The value of `COMPILER_PATH' is a colon-separated list of
|
||
directories, much like `PATH'. GNU CC tries the directories thus
|
||
specified when searching for subprograms, if it can't find the
|
||
subprograms using `GCC_EXEC_PREFIX'.
|
||
|
||
`LIBRARY_PATH'
|
||
The value of `LIBRARY_PATH' is a colon-separated list of
|
||
directories, much like `PATH'. When configured as a native
|
||
compiler, GNU CC tries the directories thus specified when
|
||
searching for special linker files, if it can't find them using
|
||
`GCC_EXEC_PREFIX'. Linking using GNU CC also uses these
|
||
directories when searching for ordinary libraries for the `-l'
|
||
option (but directories specified with `-L' come first).
|
||
|
||
`C_INCLUDE_PATH'
|
||
`CPLUS_INCLUDE_PATH'
|
||
`OBJC_INCLUDE_PATH'
|
||
These environment variables pertain to particular languages. Each
|
||
variable's value is a colon-separated list of directories, much
|
||
like `PATH'. When GNU CC searches for header files, it tries the
|
||
directories listed in the variable for the language you are using,
|
||
after the directories specified with `-I' but before the standard
|
||
header file directories.
|
||
|
||
`DEPENDENCIES_OUTPUT'
|
||
If this variable is set, its value specifies how to output
|
||
dependencies for Make based on the header files processed by the
|
||
compiler. This output looks much like the output from the `-M'
|
||
option (*note Preprocessor Options::.), but it goes to a separate
|
||
file, and is in addition to the usual results of compilation.
|
||
|
||
The value of `DEPENDENCIES_OUTPUT' can be just a file name, in
|
||
which case the Make rules are written to that file, guessing the
|
||
target name from the source file name. Or the value can have the
|
||
form `FILE TARGET', in which case the rules are written to file
|
||
FILE using TARGET as the target name.
|
||
|
||
|
||
File: gcc.info, Node: Running Protoize, Prev: Environment Variables, Up: Invoking GCC
|
||
|
||
Running Protoize
|
||
================
|
||
|
||
The program `protoize' is an optional part of GNU C. You can use it
|
||
to add prototypes to a program, thus converting the program to ANSI C
|
||
in one respect. The companion program `unprotoize' does the reverse:
|
||
it removes argument types from any prototypes that are found.
|
||
|
||
When you run these programs, you must specify a set of source files
|
||
as command line arguments. The conversion programs start out by
|
||
compiling these files to see what functions they define. The
|
||
information gathered about a file FOO is saved in a file named `FOO.X'.
|
||
|
||
After scanning comes actual conversion. The specified files are all
|
||
eligible to be converted; any files they include (whether sources or
|
||
just headers) are eligible as well.
|
||
|
||
But not all the eligible files are converted. By default,
|
||
`protoize' and `unprotoize' convert only source and header files in the
|
||
current directory. You can specify additional directories whose files
|
||
should be converted with the `-d DIRECTORY' option. You can also
|
||
specify particular files to exclude with the `-x FILE' option. A file
|
||
is converted if it is eligible, its directory name matches one of the
|
||
specified directory names, and its name within the directory has not
|
||
been excluded.
|
||
|
||
Basic conversion with `protoize' consists of rewriting most function
|
||
definitions and function declarations to specify the types of the
|
||
arguments. The only ones not rewritten are those for varargs functions.
|
||
|
||
`protoize' optionally inserts prototype declarations at the
|
||
beginning of the source file, to make them available for any calls that
|
||
precede the function's definition. Or it can insert prototype
|
||
declarations with block scope in the blocks where undeclared functions
|
||
are called.
|
||
|
||
Basic conversion with `unprotoize' consists of rewriting most
|
||
function declarations to remove any argument types, and rewriting
|
||
function definitions to the old-style pre-ANSI form.
|
||
|
||
Both conversion programs print a warning for any function
|
||
declaration or definition that they can't convert. You can suppress
|
||
these warnings with `-q'.
|
||
|
||
The output from `protoize' or `unprotoize' replaces the original
|
||
source file. The original file is renamed to a name ending with
|
||
`.save'. If the `.save' file already exists, then the source file is
|
||
simply discarded.
|
||
|
||
`protoize' and `unprotoize' both depend on GNU CC itself to scan the
|
||
program and collect information about the functions it uses. So
|
||
neither of these programs will work until GNU CC is installed.
|
||
|
||
Here is a table of the options you can use with `protoize' and
|
||
`unprotoize'. Each option works with both programs unless otherwise
|
||
stated.
|
||
|
||
`-B DIRECTORY'
|
||
Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the
|
||
usual directory (normally `/usr/local/lib'). This file contains
|
||
prototype information about standard system functions. This option
|
||
applies only to `protoize'.
|
||
|
||
`-c COMPILATION-OPTIONS'
|
||
Use COMPILATION-OPTIONS as the options when running `gcc' to
|
||
produce the `.X' files. The special option `-aux-info' is always
|
||
passed in addition, to tell `gcc' to write a `.X' file.
|
||
|
||
Note that the compilation options must be given as a single
|
||
argument to `protoize' or `unprotoize'. If you want to specify
|
||
several `gcc' options, you must quote the entire set of
|
||
compilation options to make them a single word in the shell.
|
||
|
||
There are certain `gcc' arguments that you cannot use, because they
|
||
would produce the wrong kind of output. These include `-g', `-O',
|
||
`-c', `-S', and `-o' If you include these in the
|
||
COMPILATION-OPTIONS, they are ignored.
|
||
|
||
`-C'
|
||
Rename files to end in `.C' instead of `.c'. This is convenient
|
||
if you are converting a C program to C++. This option applies
|
||
only to `protoize'.
|
||
|
||
`-g'
|
||
Add explicit global declarations. This means inserting explicit
|
||
declarations at the beginning of each source file for each function
|
||
that is called in the file and was not declared. These
|
||
declarations precede the first function definition that contains a
|
||
call to an undeclared function. This option applies only to
|
||
`protoize'.
|
||
|
||
`-i STRING'
|
||
Indent old-style parameter declarations with the string STRING.
|
||
This option applies only to `protoize'.
|
||
|
||
`unprotoize' converts prototyped function definitions to old-style
|
||
function definitions, where the arguments are declared between the
|
||
argument list and the initial `{'. By default, `unprotoize' uses
|
||
five spaces as the indentation. If you want to indent with just
|
||
one space instead, use `-i " "'.
|
||
|
||
`-k'
|
||
Keep the `.X' files. Normally, they are deleted after conversion
|
||
is finished.
|
||
|
||
`-l'
|
||
Add explicit local declarations. `protoize' with `-l' inserts a
|
||
prototype declaration for each function in each block which calls
|
||
the function without any declaration. This option applies only to
|
||
`protoize'.
|
||
|
||
`-n'
|
||
Make no real changes. This mode just prints information about the
|
||
conversions that would have been done without `-n'.
|
||
|
||
`-N'
|
||
Make no `.save' files. The original files are simply deleted.
|
||
Use this option with caution.
|
||
|
||
`-p PROGRAM'
|
||
Use the program PROGRAM as the compiler. Normally, the name `gcc'
|
||
is used.
|
||
|
||
`-q'
|
||
Work quietly. Most warnings are suppressed.
|
||
|
||
`-v'
|
||
Print the version number, just like `-v' for `gcc'.
|
||
|
||
If you need special compiler options to compile one of your program's
|
||
source files, then you should generate that file's `.X' file specially,
|
||
by running `gcc' on that source file with the appropriate options and
|
||
the option `-aux-info'. Then run `protoize' on the entire set of
|
||
files. `protoize' will use the existing `.X' file because it is newer
|
||
than the source file. For example:
|
||
|
||
gcc -Dfoo=bar file1.c -aux-info
|
||
protoize *.c
|
||
|
||
You need to include the special files along with the rest in the
|
||
`protoize' command, even though their `.X' files already exist, because
|
||
otherwise they won't get converted.
|
||
|
||
*Note Protoize Caveats::, for more information on how to use
|
||
`protoize' successfully.
|
||
|