In processor names, a final `000' can be abbreviated as `k' (for example, `-march=r2k'). Prefixes are optional, and `vr' may be written `r'.
Names of the form `nf2_1' refer to processors with FPUs clocked at half the rate of the core, names of the form `nf1_1' refer to processors with FPUs clocked at the same rate as the core, and names of the form `nf3_2' refer to processors with FPUs clocked a ratio of 3:2 with respect to the core. For compatibility reasons, `nf' is accepted as a synonym for `nf2_1' while `nx' and `bfx' are accepted as synonyms for `nf1_1'.
GCC defines two macros based on the value of this option. The first is `_MIPS_ARCH', which gives the name of target architecture, as a string. The second has the form `_MIPS_ARCH_foo', where foo is the capitalized value of `_MIPS_ARCH'. For example, `-march=r2000' will set `_MIPS_ARCH' to `"r2000"' and define the macro `_MIPS_ARCH_R2000'.
Note that the `_MIPS_ARCH' macro uses the processor names given
above. In other words, it will have the full prefix and will not
abbreviate `000' as `k'. In the case of `from-abi',
the macro names the resolved architecture (either `"mips1"' or
`"mips3"'). It names the default architecture when no
-march option is given.
When this option is not used, GCC will optimize for the processor specified by -march. By using -march and -mtune together, it is possible to generate code that will run on a family of processors, but optimize the code for one particular member of that family.
`-mtune' defines the macros `_MIPS_TUNE' and
`_MIPS_TUNE_foo', which work in the same way as the
`-march' ones described above.
MIPS16 code generation can also be controlled on a per-function basis
by means of
See Function Attributes, for more information.
For example, non-MIPS16 code cannot jump directly to MIPS16 code;
it must either use a call or an indirect jump. -minterlink-mips16
therefore disables direct jumps unless GCC knows that the target of the
jump is not MIPS16.
Note that the EABI has a 32-bit and a 64-bit variant. GCC normally generates 64-bit code when you select a 64-bit architecture, but you can use -mgp32 to get 32-bit code instead.
For information about the O64 ABI, see http://gcc.gnu.org/projects/mipso64-abi.html.
GCC supports a variant of the o32 ABI in which floating-point registers are 64 rather than 32 bits wide. You can select this combination with -mabi=32 -mfp64. This ABI relies on the `mthc1' and `mfhc1' instructions and is therefore only supported for MIPS32R2 processors.
The register assignments for arguments and return values remain the
same, but each scalar value is passed in a single 64-bit register
rather than a pair of 32-bit registers. For example, scalar
floating-point values are returned in `$f0' only, not a
`$f0'/`$f1' pair. The set of call-saved registers also
remains the same, but all 64 bits are saved.
All -mabicalls code has traditionally been position-independent, regardless of options like -fPIC and -fpic. However, as an extension, the GNU toolchain allows executables to use absolute accesses for locally-binding symbols. It can also use shorter GP initialization sequences and generate direct calls to locally-defined functions. This mode is selected by -mno-shared.
-mno-shared depends on binutils 2.16 or higher and generates objects that can only be linked by the GNU linker. However, the option does not affect the ABI of the final executable; it only affects the ABI of relocatable objects. Using -mno-shared will generally make executables both smaller and quicker.
-mshared is the default.
GCC normally uses a single instruction to load values from the GOT. While this is relatively efficient, it will only work if the GOT is smaller than about 64k. Anything larger will cause the linker to report an error such as:
relocation truncated to fit: R_MIPS_GOT16 foobar
If this happens, you should recompile your code with -mxgot. It should then work with very large GOTs, although it will also be less efficient, since it will take three instructions to fetch the value of a global symbol.
Note that some linkers can create multiple GOTs. If you have such a linker, you should only need to use -mxgot when a single object file accesses more than 64k's worth of GOT entries. Very few do.
These options have no effect unless GCC is generating position
-mllsc is useful if the runtime environment can emulate the
instructions and -mno-llsc can be useful when compiling for
nonstandard ISAs. You can make either option the default by
configuring GCC with --with-llsc and --without-llsc
respectively. --with-llsc is the default for some
configurations; see the installation documentation for details.
longtypes to be 64 bits wide. See -mlong32 for an explanation of the default and the way that the pointer size is determined.
int, and pointer types to be 32 bits wide.
The default size of
longs and pointers depends on
the ABI. All the supported ABIs use 32-bit
ints. The n64 ABI
longs, as does the 64-bit EABI; the others use
longs. Pointers are the same size as
or the same size as integer registers, whichever is smaller.
The default -G option depends on the configuration.
If the linker complains that an application is using too much small data,
you might want to try rebuilding the less performance-critical parts with
-mno-local-sdata. You might also want to build large
libraries with -mno-local-sdata, so that the libraries leave
more room for the main program.
If you compile a module Mod with -mextern-sdata -G
num -mgpopt, and Mod references a variable Var
that is no bigger than num bytes, you must make sure that Var
is placed in a small data section. If Var is defined by another
module, you must either compile that module with a high-enough
-G setting or attach a
section attribute to Var's
definition. If Var is common, you must link the application
with a high-enough -G setting.
The easiest way of satisfying these restrictions is to compile
and link every module with the same -G option. However,
you may wish to build a library that supports several different
small data limits. You can do this by compiling the library with
the highest supported -G setting and additionally using
-mno-extern-sdata to stop the library from making assumptions
about externally-defined data.
-mno-gpopt is useful for cases where the
might not hold the value of
_gp. For example, if the code is
part of a library that might be used in a boot monitor, programs that
call boot monitor routines will pass an unknown value in
(In such situations, the boot monitor itself would usually be compiled
-mno-gpopt implies -mno-local-sdata and
constvariables in the read-only data section. This option is only meaningful in conjunction with -membedded-data.
%lo()assembler relocation operators. This option has been superseded by -mexplicit-relocs but is retained for backwards compatibility.
-mexplicit-relocs is the default if GCC was configured
to use an assembler that supports relocation operators.
The default is -mcheck-zero-division.
SIGFPE). Use -mdivide-traps to allow conditional traps on architectures that support them and -mdivide-breaks to force the use of breaks.
The default is usually -mdivide-traps, but this can be
overridden at configure time using --with-divide=breaks.
Divide-by-zero checks can be completely disabled using
memcpy()for non-trivial block moves. The default is -mno-memcpy, which allows GCC to inline most constant-sized copies.
jalinstruction. Calling functions using
jalis more efficient but requires the caller and callee to be in the same 256 megabyte segment.
This option has no effect on abicalls code. The default is
mulinstructions, as provided by the R4650 ISA.
When multiply-accumulate instructions are used, the intermediate
product is calculated to infinite precision and is not subject to
the FCSR Flush to Zero bit. This may be undesirable in some
dmultudoes not always produce the correct result.
ddivdo not always produce the correct result if one of the operands is negative.
Other VR4120 errata require a nop to be inserted between certain pairs of
instructions. These errata are handled by the assembler, not by GCC itself.
mfhierrata. The workarounds are implemented by the assembler rather than by GCC, although GCC will avoid using
mfhiif the VR4130
dmacchiinstructions are available instead.
_flush_func(), that is, the address of the memory range for which the cache is being flushed, the size of the memory range, and the number 3 (to flush both caches). The default depends on the target GCC was configured for, but commonly is either `_flush_func' or `__cpu_flush'.
For instance, on the SB-1, if FP exceptions are disabled, and we are emitting
64-bit code, then we can use both FP pipes. Otherwise, we can only use one
This option only has an effect when optimizing for the VR4130. It normally makes code faster, but at the expense of making it bigger. It is enabled by default at optimization level -O3.