1211 lines
48 KiB
Plaintext
1211 lines
48 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
|
||
input file ../../gcc-2.95.2/gcc/gcc.texi.
|
||
|
||
INFO-DIR-SECTION Programming
|
||
START-INFO-DIR-ENTRY
|
||
* gcc: (gcc). The GNU Compiler Collection.
|
||
END-INFO-DIR-ENTRY
|
||
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,
|
||
1999 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" and "Funding
|
||
for Free Software" 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 "Funding for Free Software", 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: HPPA Options, Next: Intel 960 Options, Prev: i386 Options, Up: Submodel Options
|
||
|
||
HPPA Options
|
||
------------
|
||
|
||
These `-m' options are defined for the HPPA family of computers:
|
||
|
||
`-march=ARCHITECTURE TYPE'
|
||
Generate code for the specified architecture. The choices for
|
||
ARCHITECTURE TYPE are `1.0' for PA 1.0, `1.1' for PA 1.1, and
|
||
`2.0' for PA 2.0 processors. Refer to `/usr/lib/sched.models' on
|
||
an HP-UX system to determine the proper architecture option for
|
||
your machine. Code compiled for lower numbered architectures will
|
||
run on higher numbered architectures, but not the other way around.
|
||
|
||
PA 2.0 support currently requires gas snapshot 19990413 or later.
|
||
The next release of binutils (current is 2.9.1) will probably
|
||
contain PA 2.0 support.
|
||
|
||
`-mpa-risc-1-0'
|
||
`-mpa-risc-1-1'
|
||
`-mpa-risc-2-0'
|
||
Synonyms for -march=1.0, -march=1.1, and -march=2.0 respectively.
|
||
|
||
`-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.
|
||
|
||
`-mjump-in-delay'
|
||
Fill delay slots of function calls with unconditional jump
|
||
instructions by modifying the return pointer for the function call
|
||
to be the target of the conditional jump.
|
||
|
||
`-mdisable-fpregs'
|
||
Prevent floating point registers from being used in any manner.
|
||
This is necessary for compiling kernels which perform lazy context
|
||
switching of floating point registers. If you use this option and
|
||
attempt to perform floating point operations, the compiler will
|
||
abort.
|
||
|
||
`-mdisable-indexing'
|
||
Prevent the compiler from using indexing address modes. This
|
||
avoids some rather obscure problems when compiling MIG generated
|
||
code under MACH.
|
||
|
||
`-mno-space-regs'
|
||
Generate code that assumes the target has no space registers.
|
||
This allows GCC to generate faster indirect calls and use unscaled
|
||
index address modes.
|
||
|
||
Such code is suitable for level 0 PA systems and kernels.
|
||
|
||
`-mfast-indirect-calls'
|
||
Generate code that assumes calls never cross space boundaries.
|
||
This allows GCC to emit code which performs faster indirect calls.
|
||
|
||
This option will not work in the presense of shared libraries or
|
||
nested functions.
|
||
|
||
`-mspace'
|
||
Optimize for space rather than execution time. Currently this only
|
||
enables out of line function prologues and epilogues. This option
|
||
is incompatible with PIC code generation and profiling.
|
||
|
||
`-mlong-load-store'
|
||
Generate 3-instruction load and store sequences as sometimes
|
||
required by the HP-UX 10 linker. This is equivalent to the `+k'
|
||
option to the HP compilers.
|
||
|
||
`-mportable-runtime'
|
||
Use the portable calling conventions proposed by HP for ELF
|
||
systems.
|
||
|
||
`-mgas'
|
||
Enable the use of assembler directives only GAS understands.
|
||
|
||
`-mschedule=CPU TYPE'
|
||
Schedule code according to the constraints for the machine type
|
||
CPU TYPE. The choices for CPU TYPE are `700' `7100', `7100LC',
|
||
`7200', and `8000'. Refer to `/usr/lib/sched.models' on an HP-UX
|
||
system to determine the proper scheduling option for your machine.
|
||
|
||
`-mlinker-opt'
|
||
Enable the optimization pass in the HPUX linker. Note this makes
|
||
symbolic debugging impossible. It also triggers a bug in the HPUX
|
||
8 and HPUX 9 linkers in which they give bogus error messages when
|
||
linking some programs.
|
||
|
||
`-msoft-float'
|
||
Generate output containing library calls for floating point.
|
||
*Warning:* the requisite libraries are not available for all HPPA
|
||
targets. Normally the facilities of the machine's usual C
|
||
compiler are used, but this cannot be done directly in
|
||
cross-compilation. You must make your own arrangements to provide
|
||
suitable library functions for cross-compilation. The embedded
|
||
target `hppa1.1-*-pro' does provide software floating point
|
||
support.
|
||
|
||
`-msoft-float' changes the calling convention in the output file;
|
||
therefore, it is only useful if you compile *all* of a program with
|
||
this option. In particular, you need to compile `libgcc.a', the
|
||
library that comes with GCC, with `-msoft-float' in order for this
|
||
to work.
|
||
|
||
|
||
File: gcc.info, Node: Intel 960 Options, Next: DEC Alpha Options, Prev: HPPA Options, Up: Submodel Options
|
||
|
||
Intel 960 Options
|
||
-----------------
|
||
|
||
These `-m' options are defined for the Intel 960 implementations:
|
||
|
||
`-mCPU TYPE'
|
||
Assume the defaults for the machine type CPU TYPE for some of the
|
||
other options, including instruction scheduling, floating point
|
||
support, and addressing modes. The choices for CPU TYPE are `ka',
|
||
`kb', `mc', `ca', `cf', `sa', and `sb'. The default is `kb'.
|
||
|
||
`-mnumerics'
|
||
`-msoft-float'
|
||
The `-mnumerics' option indicates that the processor does support
|
||
floating-point instructions. The `-msoft-float' option indicates
|
||
that floating-point support should not be assumed.
|
||
|
||
`-mleaf-procedures'
|
||
`-mno-leaf-procedures'
|
||
Do (or do not) attempt to alter leaf procedures to be callable
|
||
with the `bal' instruction as well as `call'. This will result in
|
||
more efficient code for explicit calls when the `bal' instruction
|
||
can be substituted by the assembler or linker, but less efficient
|
||
code in other cases, such as calls via function pointers, or using
|
||
a linker that doesn't support this optimization.
|
||
|
||
`-mtail-call'
|
||
`-mno-tail-call'
|
||
Do (or do not) make additional attempts (beyond those of the
|
||
machine-independent portions of the compiler) to optimize
|
||
tail-recursive calls into branches. You may not want to do this
|
||
because the detection of cases where this is not valid is not
|
||
totally complete. The default is `-mno-tail-call'.
|
||
|
||
`-mcomplex-addr'
|
||
`-mno-complex-addr'
|
||
Assume (or do not assume) that the use of a complex addressing
|
||
mode is a win on this implementation of the i960. Complex
|
||
addressing modes may not be worthwhile on the K-series, but they
|
||
definitely are on the C-series. The default is currently
|
||
`-mcomplex-addr' for all processors except the CB and CC.
|
||
|
||
`-mcode-align'
|
||
`-mno-code-align'
|
||
Align code to 8-byte boundaries for faster fetching (or don't
|
||
bother). Currently turned on by default for C-series
|
||
implementations only.
|
||
|
||
`-mic-compat'
|
||
`-mic2.0-compat'
|
||
`-mic3.0-compat'
|
||
Enable compatibility with iC960 v2.0 or v3.0.
|
||
|
||
`-masm-compat'
|
||
`-mintel-asm'
|
||
Enable compatibility with the iC960 assembler.
|
||
|
||
`-mstrict-align'
|
||
`-mno-strict-align'
|
||
Do not permit (do permit) unaligned accesses.
|
||
|
||
`-mold-align'
|
||
Enable structure-alignment compatibility with Intel's gcc release
|
||
version 1.3 (based on gcc 1.37). This option implies
|
||
`-mstrict-align'.
|
||
|
||
`-mlong-double-64'
|
||
Implement type `long double' as 64-bit floating point numbers.
|
||
Without the option `long double' is implemented by 80-bit floating
|
||
point numbers. The only reason we have it because there is no
|
||
128-bit `long double' support in `fp-bit.c' yet. So it is only
|
||
useful for people using soft-float targets. Otherwise, we should
|
||
recommend against use of it.
|
||
|
||
|
||
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. GCC 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 GCC 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 GCC 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 GCC 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 GCC 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. GCC 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,
|
||
GCC 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'
|
||
`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.
|
||
|
||
`-mmemory-latency=TIME'
|
||
Sets the latency the scheduler should assume for typical memory
|
||
references as seen by the application. This number is highly
|
||
dependant on the memory access patterns used by the application
|
||
and the size of the external cache on the machine.
|
||
|
||
Valid options for TIME are
|
||
|
||
`NUMBER'
|
||
A decimal number representing clock cycles.
|
||
|
||
`L1'
|
||
`L2'
|
||
`L3'
|
||
`main'
|
||
The compiler contains estimates of the number of clock cycles
|
||
for "typical" EV4 & EV5 hardware for the Level 1, 2 & 3 caches
|
||
(also called Dcache, Scache, and Bcache), as well as to main
|
||
memory. Note that L3 is only valid for EV5.
|
||
|
||
|
||
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.
|
||
|
||
`-mdalign'
|
||
Align doubles at 64 bit boundaries. Note that this changes the
|
||
calling conventions, and thus some functions from the standard C
|
||
library will not work unless you recompile it first with -mdalign.
|
||
|
||
`-mrelax'
|
||
Shorten some address references at link time, when possible; uses
|
||
the linker option `-relax'.
|
||
|
||
|
||
File: gcc.info, Node: System V Options, Next: TMS320C3x/C4x 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: TMS320C3x/C4x Options, Next: V850 Options, Prev: System V Options, Up: Submodel Options
|
||
|
||
TMS320C3x/C4x Options
|
||
---------------------
|
||
|
||
These `-m' options are defined for TMS320C3x/C4x implementations:
|
||
|
||
`-mcpu=CPU_TYPE'
|
||
Set the instruction set, register set, and instruction scheduling
|
||
parameters for machine type CPU_TYPE. Supported values for
|
||
CPU_TYPE are `c30', `c31', `c32', `c40', and `c44'. The default
|
||
is `c40' to generate code for the TMS320C40.
|
||
|
||
`-mbig-memory'
|
||
|
||
`-mbig'
|
||
`-msmall-memory'
|
||
`-msmall'
|
||
Generates code for the big or small memory model. The small memory
|
||
model assumed that all data fits into one 64K word page. At
|
||
run-time the data page (DP) register must be set to point to the
|
||
64K page containing the .bss and .data program sections. The big
|
||
memory model is the default and requires reloading of the DP
|
||
register for every direct memory access.
|
||
|
||
`-mbk'
|
||
`-mno-bk'
|
||
Allow (disallow) allocation of general integer operands into the
|
||
block count register BK.
|
||
|
||
`-mdb'
|
||
`-mno-db'
|
||
Enable (disable) generation of code using decrement and branch,
|
||
DBcond(D), instructions. This is enabled by default for the C4x.
|
||
To be on the safe side, this is disabled for the C3x, since the
|
||
maximum iteration count on the C3x is 2^23 + 1 (but who iterates
|
||
loops more than 2^23 times on the C3x?). Note that GCC will try
|
||
to reverse a loop so that it can utilise the decrement and branch
|
||
instruction, but will give up if there is more than one memory
|
||
reference in the loop. Thus a loop where the loop counter is
|
||
decremented can generate slightly more efficient code, in cases
|
||
where the RPTB instruction cannot be utilised.
|
||
|
||
`-mdp-isr-reload'
|
||
`-mparanoid'
|
||
Force the DP register to be saved on entry to an interrupt service
|
||
routine (ISR), reloaded to point to the data section, and restored
|
||
on exit from the ISR. This should not be required unless someone
|
||
has violated the small memory model by modifying the DP register,
|
||
say within an object library.
|
||
|
||
`-mmpyi'
|
||
`-mno-mpyi'
|
||
For the C3x use the 24-bit MPYI instruction for integer multiplies
|
||
instead of a library call to guarantee 32-bit results. Note that
|
||
if one of the operands is a constant, then the multiplication will
|
||
be performed using shifts and adds. If the -mmpyi option is not
|
||
specified for the C3x, then squaring operations are performed
|
||
inline instead of a library call.
|
||
|
||
`-mfast-fix'
|
||
`-mno-fast-fix'
|
||
The C3x/C4x FIX instruction to convert a floating point value to an
|
||
integer value chooses the nearest integer less than or equal to the
|
||
floating point value rather than to the nearest integer. Thus if
|
||
the floating point number is negative, the result will be
|
||
incorrectly truncated an additional code is necessary to detect
|
||
and correct this case. This option can be used to disable
|
||
generation of the additional code required to correct the result.
|
||
|
||
`-mrptb'
|
||
`-mno-rptb'
|
||
Enable (disable) generation of repeat block sequences using the
|
||
RPTB instruction for zero overhead looping. The RPTB construct is
|
||
only used for innermost loops that do not call functions or jump
|
||
across the loop boundaries. There is no advantage having nested
|
||
RPTB loops due to the overhead required to save and restore the
|
||
RC, RS, and RE registers. This is enabled by default with -O2.
|
||
|
||
`-mrpts=COUNT'
|
||
`-mno-rpts'
|
||
Enable (disable) the use of the single instruction repeat
|
||
instruction RPTS. If a repeat block contains a single
|
||
instruction, and the loop count can be guaranteed to be less than
|
||
the value COUNT, GCC will emit a RPTS instruction instead of a
|
||
RPTB. If no value is specified, then a RPTS will be emitted even
|
||
if the loop count cannot be determined at compile time. Note that
|
||
the repeated instruction following RPTS does not have to be
|
||
reloaded from memory each iteration, thus freeing up the CPU buses
|
||
for oeprands. However, since interrupts are blocked by this
|
||
instruction, it is disabled by default.
|
||
|
||
`-mloop-unsigned'
|
||
`-mno-loop-unsigned'
|
||
The maximum iteration count when using RPTS and RPTB (and DB on
|
||
the C40) is 2^31 + 1 since these instructions test if the
|
||
iteration count is negative to terminate the loop. If the
|
||
iteration count is unsigned there is a possibility than the 2^31 +
|
||
1 maximum iteration count may be exceeded. This switch allows an
|
||
unsigned iteration count.
|
||
|
||
`-mti'
|
||
Try to emit an assembler syntax that the TI assembler (asm30) is
|
||
happy with. This also enforces compatibility with the API
|
||
employed by the TI C3x C compiler. For example, long doubles are
|
||
passed as structures rather than in floating point registers.
|
||
|
||
`-mregparm'
|
||
`-mmemparm'
|
||
Generate code that uses registers (stack) for passing arguments to
|
||
functions. By default, arguments are passed in registers where
|
||
possible rather than by pushing arguments on to the stack.
|
||
|
||
`-mparallel-insns'
|
||
`-mno-parallel-insns'
|
||
Allow the generation of parallel instructions. This is enabled by
|
||
default with -O2.
|
||
|
||
`-mparallel-mpy'
|
||
`-mno-parallel-mpy'
|
||
Allow the generation of MPY||ADD and MPY||SUB parallel
|
||
instructions, provided -mparallel-insns is also specified. These
|
||
instructions have tight register constraints which can pessimize
|
||
the code generation of large functions.
|
||
|
||
|
||
File: gcc.info, Node: V850 Options, Next: ARC Options, Prev: TMS320C3x/C4x 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: ARC Options, Next: NS32K Options, Prev: V850 Options, Up: Submodel Options
|
||
|
||
ARC Options
|
||
-----------
|
||
|
||
These options are defined for ARC implementations:
|
||
|
||
`-EL'
|
||
Compile code for little endian mode. This is the default.
|
||
|
||
`-EB'
|
||
Compile code for big endian mode.
|
||
|
||
`-mmangle-cpu'
|
||
Prepend the name of the cpu to all public symbol names. In
|
||
multiple-processor systems, there are many ARC variants with
|
||
different instruction and register set characteristics. This flag
|
||
prevents code compiled for one cpu to be linked with code compiled
|
||
for another. No facility exists for handling variants that are
|
||
"almost identical". This is an all or nothing option.
|
||
|
||
`-mcpu=CPU'
|
||
Compile code for ARC variant CPU. Which variants are supported
|
||
depend on the configuration. All variants support `-mcpu=base',
|
||
this is the default.
|
||
|
||
`-mtext=TEXT SECTION'
|
||
`-mdata=DATA SECTION'
|
||
`-mrodata=READONLY DATA SECTION'
|
||
Put functions, data, and readonly data in TEXT SECTION, DATA
|
||
SECTION, and READONLY DATA SECTION respectively by default. This
|
||
can be overridden with the `section' attribute. *Note Variable
|
||
Attributes::.
|
||
|
||
|
||
File: gcc.info, Node: NS32K Options, Prev: ARC Options, Up: Submodel Options
|
||
|
||
NS32K Options
|
||
-------------
|
||
|
||
These are the `-m' options defined for the 32000 series. The default
|
||
values for these options depends on which style of 32000 was selected
|
||
when the compiler was configured; the defaults for the most common
|
||
choices are given below.
|
||
|
||
`-m32032'
|
||
`-m32032'
|
||
Generate output for a 32032. This is the default when the
|
||
compiler is configured for 32032 and 32016 based systems.
|
||
|
||
`-m32332'
|
||
`-m32332'
|
||
Generate output for a 32332. This is the default when the
|
||
compiler is configured for 32332-based systems.
|
||
|
||
`-m32532'
|
||
`-m32532'
|
||
Generate output for a 32532. This is the default when the
|
||
compiler is configured for 32532-based systems.
|
||
|
||
`-m32081'
|
||
Generate output containing 32081 instructions for floating point.
|
||
This is the default for all systems.
|
||
|
||
`-m32381'
|
||
Generate output containing 32381 instructions for floating point.
|
||
This also implies `-m32081'. The 32381 is only compatible with the
|
||
32332 and 32532 cpus. This is the default for the pc532-netbsd
|
||
configuration.
|
||
|
||
`-mmulti-add'
|
||
Try and generate multiply-add floating point instructions `polyF'
|
||
and `dotF'. This option is only available if the `-m32381' option
|
||
is in effect. Using these instructions requires changes to to
|
||
register allocation which generally has a negative impact on
|
||
performance. This option should only be enabled when compiling
|
||
code particularly likely to make heavy use of multiply-add
|
||
instructions.
|
||
|
||
`-mnomulti-add'
|
||
Do not try and generate multiply-add floating point instructions
|
||
`polyF' and `dotF'. This is the default on all platforms.
|
||
|
||
`-msoft-float'
|
||
Generate output containing library calls for floating point.
|
||
*Warning:* the requisite libraries may not be available.
|
||
|
||
`-mnobitfield'
|
||
Do not use the bit-field instructions. On some machines it is
|
||
faster to use shifting and masking operations. This is the default
|
||
for the pc532.
|
||
|
||
`-mbitfield'
|
||
Do use the bit-field instructions. This is the default for all
|
||
platforms except the pc532.
|
||
|
||
`-mrtd'
|
||
Use a different function-calling convention, in which functions
|
||
that take a fixed number of arguments return pop their arguments
|
||
on return with the `ret' instruction.
|
||
|
||
This calling convention is incompatible with the one normally used
|
||
on Unix, so you cannot use it if you need to call libraries
|
||
compiled with the Unix compiler.
|
||
|
||
Also, you must provide function prototypes for all functions that
|
||
take variable numbers of arguments (including `printf'); otherwise
|
||
incorrect code will be generated for calls to those functions.
|
||
|
||
In addition, seriously incorrect code will result if you call a
|
||
function with too many arguments. (Normally, extra arguments are
|
||
harmlessly ignored.)
|
||
|
||
This option takes its name from the 680x0 `rtd' instruction.
|
||
|
||
`-mregparam'
|
||
Use a different function-calling convention where the first two
|
||
arguments are passed in registers.
|
||
|
||
This calling convention is incompatible with the one normally used
|
||
on Unix, so you cannot use it if you need to call libraries
|
||
compiled with the Unix compiler.
|
||
|
||
`-mnoregparam'
|
||
Do not pass any arguments in registers. This is the default for all
|
||
targets.
|
||
|
||
`-msb'
|
||
It is OK to use the sb as an index register which is always loaded
|
||
with zero. This is the default for the pc532-netbsd target.
|
||
|
||
`-mnosb'
|
||
The sb register is not available for use or has not been
|
||
initialized to zero by the run time system. This is the default
|
||
for all targets except the pc532-netbsd. It is also implied
|
||
whenever `-mhimem' or `-fpic' is set.
|
||
|
||
`-mhimem'
|
||
Many ns32000 series addressing modes use displacements of up to
|
||
512MB. If an address is above 512MB then displacements from zero
|
||
can not be used. This option causes code to be generated which
|
||
can be loaded above 512MB. This may be useful for operating
|
||
systems or ROM code.
|
||
|
||
`-mnohimem'
|
||
Assume code will be loaded in the first 512MB of virtual address
|
||
space. This is the default for all platforms.
|
||
|
||
|
||
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. Generates extra code needed to propagate
|
||
exceptions. For some targets, this implies generation of frame
|
||
unwind information for all functions. This can produce significant
|
||
data size overhead, although it does not affect execution. If you
|
||
do not specify this option, it is enabled by default for languages
|
||
like C++ which 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 GCC-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', GCC defaults to whichever convention is
|
||
standard for the target. If there is no standard convention, GCC
|
||
defaults to `-fpcc-struct-return', except on targets where GCC 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 GCC 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. GCC does not consider static data items to be
|
||
volatile because of this switch.
|
||
|
||
`-fvolatile-static'
|
||
Consider all memory references to static data 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 GCC; 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, GCC 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.
|
||
|
||
It is an error to used this flag with the frame pointer or stack
|
||
pointer. Use of this flag for other registers that have fixed
|
||
pervasive roles in the machine's execution model 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.
|
||
|
||
It is an error to used this flag with the frame pointer or stack
|
||
pointer. Use of this flag for other registers that have fixed
|
||
pervasive roles in the machine's execution model 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. GCC will generate
|
||
code that is suitable for a detector of bad memory accesses such as
|
||
`Checker'.
|
||
|
||
Normally, you should compile all, or none, of your code with this
|
||
option.
|
||
|
||
If you do mix code compiled with and without this option, you must
|
||
ensure that all code that has side effects and that is called by
|
||
code compiled with this option is, itself, compiled with this
|
||
option. If you do not, you might get erroneous messages from the
|
||
detector.
|
||
|
||
If you use functions from a library that have side-effects (such as
|
||
`read'), you might not be able to recompile the library and
|
||
specify this option. In that case, you can enable the
|
||
`-fprefix-function-name' option, which requests GCC 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 might have to specify
|
||
`-fcheck-memory-usage' without `-fprefix-function-name'.
|
||
|
||
If you specify this option, you can not use the `asm' or `__asm__'
|
||
keywords in functions with memory checking enabled. The compiler
|
||
cannot understand what the `asm' statement will do, and therefore
|
||
cannot generate the appropriate code, so it is rejected. However,
|
||
the function attribute `no_check_memory_usage' will disable memory
|
||
checking within a function, and `asm' statements can be put inside
|
||
such functions. Inline expansion of a non-checked function within
|
||
a checked function is permitted; the inline function's memory
|
||
accesses won't be checked, but the rest will.
|
||
|
||
If you move your `asm' statements to non-checked inline functions,
|
||
but they do access memory, you can add calls to the support code
|
||
in your inline function, to indicate any reads, writes, or copies
|
||
being done. These calls would be similar to those done in the
|
||
stubs described above.
|
||
|
||
`-fprefix-function-name'
|
||
Request GCC to add a prefix to the symbols generated for function
|
||
names. GCC 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 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);
|
||
}
|
||
|
||
GCC 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'.
|
||
|
||
`-finstrument-functions'
|
||
Generate instrumentation calls for entry and exit to functions.
|
||
Just after function entry and just before function exit, the
|
||
following profiling functions will be called with the address of
|
||
the current function and its call site. (On some platforms,
|
||
`__builtin_return_address' does not work beyond the current
|
||
function, so the call site information may not be available to the
|
||
profiling functions otherwise.)
|
||
|
||
void __cyg_profile_func_enter (void *this_fn, void *call_site);
|
||
void __cyg_profile_func_exit (void *this_fn, void *call_site);
|
||
|
||
The first argument is the address of the start of the current
|
||
function, which may be looked up exactly in the symbol table.
|
||
|
||
This instrumentation is also done for functions expanded inline in
|
||
other functions. The profiling calls will indicate where,
|
||
conceptually, the inline function is entered and exited. This
|
||
means that addressable versions of such functions must be
|
||
available. If all your uses of a function are expanded inline,
|
||
this may mean an additional expansion of code size. If you use
|
||
`extern inline' in your C code, an addressable version of such
|
||
functions must be provided. (This is normally the case anyways,
|
||
but if you get lucky and the optimizer always expands the
|
||
functions inline, you might have gotten away without providing
|
||
static copies.)
|
||
|
||
A function may be given the attribute `no_instrument_function', in
|
||
which case this instrumentation will not be done. This can be
|
||
used, for example, for the profiling functions listed above,
|
||
high-priority interrupt routines, and any functions from which the
|
||
profiling functions cannot safely be called (perhaps signal
|
||
handlers, if the profiling routines generate output or allocate
|
||
memory).
|
||
|
||
`-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.
|
||
|
||
`-fargument-alias'
|
||
`-fargument-noalias'
|
||
`-fargument-noalias-global'
|
||
Specify the possible relationships among parameters and between
|
||
parameters and global data.
|
||
|
||
`-fargument-alias' specifies that arguments (parameters) may alias
|
||
each other and may alias global storage. `-fargument-noalias'
|
||
specifies that arguments do not alias each other, but may alias
|
||
global storage. `-fargument-noalias-global' specifies that
|
||
arguments do not alias each other and do not alias global storage.
|
||
|
||
Each language will automatically use whatever option is required by
|
||
the language standard. You should not need to use these options
|
||
yourself.
|
||
|
||
`-fleading-underscore'
|
||
This option and its counterpart, -fno-leading-underscore, forcibly
|
||
change the way C symbols are represented in the object file. One
|
||
use is to help link with legacy assembly code.
|
||
|
||
Be warned that you should know what you are doing when invoking
|
||
this option, and that not all targets provide complete support for
|
||
it.
|
||
|