code-gen-options.html

gcc手册

debugging the compiler itself).

     <p><code>-fno-verbose-asm</code>, the default, causes the
extra information to be omitted and is useful when comparing two assembler
files.

     <br><dt><code>-fvolatile</code>
     <dd>Consider all memory references through pointers to be volatile.

     <br><dt><code>-fvolatile-global</code>
     <dd>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.

     <br><dt><code>-fvolatile-static</code>
     <dd>Consider all memory references to static data to be volatile.

     <br><dt><code>-fpic</code>
     <dd>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
<code>-fpic</code> does not work; in that case, recompile with <code>-fPIC</code>
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.)

     <p>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.

     <br><dt><code>-fPIC</code>
     <dd>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.

     <p>Position-independent code requires special support, and therefore works
only on certain machines.

     <br><dt><code>-ffixed-</code><var>reg</var><code></code>
     <dd>Treat the register named <var>reg</var> 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).

     <p><var>reg</var> must be the name of a register.  The register names accepted
are machine-specific and are defined in the <code>REGISTER_NAMES</code>
macro in the machine description macro file.

     <p>This flag does not have a negative form, because it specifies a
three-way choice.

     <br><dt><code>-fcall-used-</code><var>reg</var><code></code>
     <dd>Treat the register named <var>reg</var> 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 <var>reg</var>.

     <p>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.

     <p>This flag does not have a negative form, because it specifies a
three-way choice.

     <br><dt><code>-fcall-saved-</code><var>reg</var><code></code>
     <dd>Treat the register named <var>reg</var> 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 <var>reg</var> if they use it.

     <p>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.

     <p>A different sort of disaster will result from the use of this flag for
a register in which function values may be returned.

     <p>This flag does not have a negative form, because it specifies a
three-way choice.

     <br><dt><code>-fpack-struct</code>
     <dd>Pack all structure members together without holes.

     <p><strong>Warning:</strong> the <code>-fpack-struct</code> switch causes GCC to generate
code that is not binary compatible with code generated without that switch. 
Additionally, it makes the code suboptimal. 
Use it to conform to a non-default application binary interface.

     <br><dt><code>-finstrument-functions</code>
     <dd>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,
<code>__builtin_return_address</code> does not work beyond the current
function, so the call site information may not be available to the
profiling functions otherwise.)

     <pre class="example">          void __cyg_profile_func_enter (void *this_fn,
                                         void *call_site);
          void __cyg_profile_func_exit  (void *this_fn,
                                         void *call_site);
          </pre>

     <p>The first argument is the address of the start of the current function,
which may be looked up exactly in the symbol table.

     <p>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 <code>extern inline</code> 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.)

     <p>A function may be given the attribute <code>no_instrument_function</code>, 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).

     <br><dt><code>-fstack-check</code>
     <dd>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.

     <p>Note that this switch does not actually cause checking to be done; the
operating system must do that.  The switch causes generation of code
to ensure that the operating system sees the stack being extended.

     <br><dt><code>-fstack-limit-register=</code><var>reg</var><code></code>
     <dd><dt><code>-fstack-limit-symbol=</code><var>sym</var><code></code>
     <dd><dt><code>-fno-stack-limit</code>
     <dd>Generate code to ensure that the stack does not grow beyond a certain value,
either the value of a register or the address of a symbol.  If the stack
would grow beyond the value, a signal is raised.  For most targets,
the signal is raised before the stack overruns the boundary, so
it is possible to catch the signal without taking special precautions.

     <p>For instance, if the stack starts at absolute address <code>0x80000000</code>
and grows downwards, you can use the flags
<code>-fstack-limit-symbol=__stack_limit</code> and
<code>-Wl,--defsym,__stack_limit=0x7ffe0000</code> to enforce a stack limit
of 128KB.  Note that this may only work with the GNU linker.

     <br><dt><code>-fargument-alias</code>
     <dd><dt><code>-fargument-noalias</code>
     <dd><dt><code>-fargument-noalias-global</code>
     <dd>Specify the possible relationships among parameters and between
parameters and global data.

     <p><code>-fargument-alias</code> specifies that arguments (parameters) may
alias each other and may alias global storage.<br>
<code>-fargument-noalias</code> specifies that arguments do not alias
each other, but may alias global storage.<br>
<code>-fargument-noalias-global</code> specifies that arguments do not
alias each other and do not alias global storage.

     <p>Each language will automatically use whatever option is required by
the language standard.  You should not need to use these options yourself.

     <br><dt><code>-fleading-underscore</code>
     <dd>This option and its counterpart, <code>-fno-leading-underscore</code>, forcibly
change the way C symbols are represented in the object file.  One use
is to help link with legacy assembly code.

     <p><strong>Warning:</strong> the <code>-fleading-underscore</code> switch causes GCC to
generate code that is not binary compatible with code generated without that
switch.  Use it to conform to a non-default application binary interface. 
Not all targets provide complete support for this switch.

     <br><dt><code>-ftls-model=</code><var>model</var><code></code>
     <dd>Alter the thread-local storage model to be used (see <a href="Thread-Local.html#Thread-Local">Thread-Local</a>). 
The <var>model</var> argument should be one of <code>global-dynamic</code>,
<code>local-dynamic</code>, <code>initial-exec</code> or <code>local-exec</code>.

     <p>The default without <code>-fpic</code> is <code>initial-exec</code>; with
<code>-fpic</code> the default is <code>global-dynamic</code>. 
</dl>

   </body></html>