i386-and-x86-64-options.html

gcc手册

structures and arrays containing <code>long double</code> will change their size as
well as function calling convention for function taking <code>long double</code>
will be modified.

     <br><dt><code>-m96bit-long-double</code>
     <dd>Set the size of <code>long double</code> to 96 bits as required by the i386
application binary interface.  This is the default.

     <br><dt><code>-msvr3-shlib</code>
     <dd><dt><code>-mno-svr3-shlib</code>
     <dd>Control whether GCC places uninitialized local variables into the
<code>bss</code> or <code>data</code> segments.  <code>-msvr3-shlib</code> places them
into <code>bss</code>.  These options are meaningful only on System V Release 3.

     <br><dt><code>-mrtd</code>
     <dd>Use a different function-calling convention, in which functions that
take a fixed number of arguments return with the <code>ret</code> <var>num</var>
instruction, which pops their arguments while returning.  This saves one
instruction in the caller since there is no need to pop the arguments
there.

     <p>You can specify that an individual function is called with this calling
sequence with the function attribute <code>stdcall</code>.  You can also
override the <code>-mrtd</code> option by using the function attribute
<code>cdecl</code>.  See <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>.

     <p><strong>Warning:</strong> 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.

     <p>Also, you must provide function prototypes for all functions that
take variable numbers of arguments (including <code>printf</code>);
otherwise incorrect code will be generated for calls to those
functions.

     <p>In addition, seriously incorrect code will result if you call a
function with too many arguments.  (Normally, extra arguments are
harmlessly ignored.)

     <br><dt><code>-mregparm=</code><var>num</var><code></code>
     <dd>Control how many registers are used to pass integer arguments.  By
default, no registers are used to pass arguments, and at most 3
registers can be used.  You can control this behavior for a specific
function by using the function attribute <code>regparm</code>. 
See <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>.

     <p><strong>Warning:</strong> if you use this switch, and
<var>num</var> is nonzero, then you must build all modules with the same
value, including any libraries.  This includes the system libraries and
startup modules.

     <br><dt><code>-mpreferred-stack-boundary=</code><var>num</var><code></code>
     <dd>Attempt to keep the stack boundary aligned to a 2 raised to <var>num</var>
byte boundary.  If <code>-mpreferred-stack-boundary</code> is not specified,
the default is 4 (16 bytes or 128 bits), except when optimizing for code
size (<code>-Os</code>), in which case the default is the minimum correct
alignment (4 bytes for x86, and 8 bytes for x86-64).

     <p>On Pentium and PentiumPro, <code>double</code> and <code>long double</code> values
should be aligned to an 8 byte boundary (see <code>-malign-double</code>) or
suffer significant run time performance penalties.  On Pentium III, the
Streaming SIMD Extension (SSE) data type <code>__m128</code> suffers similar
penalties if it is not 16 byte aligned.

     <p>To ensure proper alignment of this values on the stack, the stack boundary
must be as aligned as that required by any value stored on the stack. 
Further, every function must be generated such that it keeps the stack
aligned.  Thus calling a function compiled with a higher preferred
stack boundary from a function compiled with a lower preferred stack
boundary will most likely misalign the stack.  It is recommended that
libraries that use callbacks always use the default setting.

     <p>This extra alignment does consume extra stack space, and generally
increases code size.  Code that is sensitive to stack space usage, such
as embedded systems and operating system kernels, may want to reduce the
preferred alignment to <code>-mpreferred-stack-boundary=2</code>.

     <br><dt><code>-mmmx</code>
     <dd><dt><code>-mno-mmx</code>
     <dd><br><dt><code>-msse</code>
     <dd><dt><code>-mno-sse</code>
     <dd><br><dt><code>-msse2</code>
     <dd><dt><code>-mno-sse2</code>
     <dd><br><dt><code>-m3dnow</code>
     <dd><dt><code>-mno-3dnow</code>
     <dd>These switches enable or disable the use of built-in functions that allow
direct access to the MMX, SSE and 3Dnow extensions of the instruction set.

     <p>See <a href="X86-Built-in-Functions.html#X86%20Built-in%20Functions">X86 Built-in Functions</a>, for details of the functions enabled
and disabled by these switches.

     <p>To have SSE/SSE2 instructions generated automatically from floating-point
code, see <code>-mfpmath=sse</code>.

     <br><dt><code>-mpush-args</code>
     <dd><dt><code>-mno-push-args</code>
     <dd>Use PUSH operations to store outgoing parameters.  This method is shorter
and usually equally fast as method using SUB/MOV operations and is enabled
by default.  In some cases disabling it may improve performance because of
improved scheduling and reduced dependencies.

     <br><dt><code>-maccumulate-outgoing-args</code>
     <dd>If enabled, the maximum amount of space required for outgoing arguments will be
computed in the function prologue.  This is faster on most modern CPUs
because of reduced dependencies, improved scheduling and reduced stack usage
when preferred stack boundary is not equal to 2.  The drawback is a notable
increase in code size.  This switch implies <code>-mno-push-args</code>.

     <br><dt><code>-mthreads</code>
     <dd>Support thread-safe exception handling on <code>Mingw32</code>.  Code that relies
on thread-safe exception handling must compile and link all code with the
<code>-mthreads</code> option.  When compiling, <code>-mthreads</code> defines
<code>-D_MT</code>; when linking, it links in a special thread helper library
<code>-lmingwthrd</code> which cleans up per thread exception handling data.

     <br><dt><code>-mno-align-stringops</code>
     <dd>Do not align destination of inlined string operations.  This switch reduces
code size and improves performance in case the destination is already aligned,
but gcc don't know about it.

     <br><dt><code>-minline-all-stringops</code>
     <dd>By default GCC inlines string operations only when destination is known to be
aligned at least to 4 byte boundary.  This enables more inlining, increase code
size, but may improve performance of code that depends on fast memcpy, strlen
and memset for short lengths.

     <br><dt><code>-momit-leaf-frame-pointer</code>
     <dd>Don't keep the frame pointer in a register for leaf functions.  This
avoids the instructions to save, set up and restore frame pointers and
makes an extra register available in leaf functions.  The option
<code>-fomit-frame-pointer</code> removes the frame pointer for all functions
which might make debugging harder. 
</dl>

   <p>These <code>-m</code> switches are supported in addition to the above
on AMD x86-64 processors in 64-bit environments.

     <dl>
<dt><code>-m32</code>
     <dd><dt><code>-m64</code>
     <dd>Generate code for a 32-bit or 64-bit environment. 
The 32-bit environment sets int, long and pointer to 32 bits and
generates code that runs on any i386 system. 
The 64-bit environment sets int to 32 bits and long and pointer
to 64 bits and generates code for AMD's x86-64 architecture.

     <br><dt><code>-mno-red-zone</code>
     <dd>Do not use a so called red zone for x86-64 code.  The red zone is mandated
by the x86-64 ABI, it is a 128-byte area beyond the location of the
stack pointer that will not be modified by signal or interrupt handlers
and therefore can be used for temporary data without adjusting the stack
pointer.  The flag <code>-mno-red-zone</code> disables this red zone.

     <br><dt><code>-mcmodel=small</code>
     <dd>Generate code for the small code model: the program and its symbols must
be linked in the lower 2 GB of the address space.  Pointers are 64 bits. 
Programs can be statically or dynamically linked.  This is the default
code model.

     <br><dt><code>-mcmodel=kernel</code>
     <dd>Generate code for the kernel code model.  The kernel runs in the
negative 2 GB of the address space. 
This model has to be used for Linux kernel code.

     <br><dt><code>-mcmodel=medium</code>
     <dd>Generate code for the medium model: The program is linked in the lower 2
GB of the address space but symbols can be located anywhere in the
address space.  Programs can be statically or dynamically linked, but
building of shared libraries are not supported with the medium model.

     <br><dt><code>-mcmodel=large</code>
     <dd>Generate code for the large model: This model makes no assumptions
about addresses and sizes of sections.  Currently GCC does not implement
this model. 
</dl>

   </body></html>