| This is Info file gcc.info, produced by Makeinfo version 1.68 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' |
| |
| `-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. |
| |