S/390 and zSeries Options (Using the GNU Compiler Collection (GCC))

#### 3.20.45 S/390 and zSeries Options ¶

These are the ‘`-m`’ options defined for the S/390 and zSeries architecture.

`-mhard-float` ¶
`-msoft-float`

  Use (do not use) the hardware floating-point instructions and registers for floating-point operations. When `-msoft-float` is specified, functions in `libgcc.a` are used to perform floating-point operations. When `-mhard-float` is specified, the compiler generates IEEE floating-point instructions. This is the default.

`-mhard-dfp` ¶
`-mno-hard-dfp`

  Use (do not use) the hardware decimal-floating-point instructions for decimal-floating-point operations. When `-mno-hard-dfp` is specified, functions in `libgcc.a` are used to perform decimal-floating-point operations. When `-mhard-dfp` is specified, the compiler generates decimal-floating-point hardware instructions. This is the default for `-march=z9-ec` or higher.

`-mlong-double-64` ¶
`-mlong-double-128`

  These switches control the size of `long double` type. A size of 64 bits makes the `long double` type equivalent to the `double` type. This is the default.

`-mbackchain` ¶
`-mno-backchain`

  Store (do not store) the address of the caller’s frame as backchain pointer into the callee’s stack frame. A backchain may be needed to allow debugging using tools that do not understand DWARF call frame information. When `-mno-packed-stack` is in effect, the backchain pointer is stored at the bottom of the stack frame; when `-mpacked-stack` is in effect, the backchain is placed into the topmost word of the 96/160 byte register save area.

  In general, code compiled with `-mbackchain` is call-compatible with code compiled with `-mno-backchain`; however, use of the backchain for debugging purposes usually requires that the whole binary is built with `-mbackchain`. Note that the combination of `-mbackchain`, `-mpacked-stack` and `-mhard-float` is not supported. In order to build a linux kernel use `-msoft-float`.

  The default is to not maintain the backchain.

`-mpacked-stack` ¶
`-mno-packed-stack`

  Use (do not use) the packed stack layout. When `-mno-packed-stack` is specified, the compiler uses the all fields of the 96/160 byte register save area only for their default purpose; unused fields still take up stack space. When `-mpacked-stack` is specified, register save slots are densely packed at the top of the register save area; unused space is reused for other purposes, allowing for more efficient use of the available stack space. However, when `-mbackchain` is also in effect, the topmost word of the save area is always used to store the backchain, and the return address register is always saved two words below the backchain.

  As long as the stack frame backchain is not used, code generated with `-mpacked-stack` is call-compatible with code generated with `-mno-packed-stack`. Note that some non-FSF releases of GCC 2.95 for S/390 or zSeries generated code that uses the stack frame backchain at run time, not just for debugging purposes. Such code is not call-compatible with code compiled with `-mpacked-stack`. Also, note that the combination of `-mbackchain`, `-mpacked-stack` and `-mhard-float` is not supported. In order to build a linux kernel use `-msoft-float`.

  The default is to not use the packed stack layout.

`-msmall-exec` ¶
`-mno-small-exec`

  Generate (or do not generate) code using the `bras` instruction to do subroutine calls. This only works reliably if the total executable size does not exceed 64k. The default is to use the `basr` instruction instead, which does not have this limitation.

`-m64` ¶
`-m31`

  When `-m31` is specified, generate code compliant to the GNU/Linux for S/390 ABI. When `-m64` is specified, generate code compliant to the GNU/Linux for zSeries ABI. This allows GCC in particular to generate 64-bit instructions. For the ‘`s390`’ targets, the default is `-m31`, while the ‘`s390x`’ targets default to `-m64`. Note, `-m31` is deprecated and support will be removed.

`-mzarch` ¶
`-mesa`

  When `-mzarch` is specified, generate code using the instructions available on z/Architecture. When `-mesa` is specified, generate code using the instructions available on ESA/390. Note that `-mesa` is not possible with `-m64`. When generating code compliant to the GNU/Linux for S/390 ABI, the default is `-mesa`. When generating code compliant to the GNU/Linux for zSeries ABI, the default is `-mzarch`.

`-mhtm` ¶
`-mno-htm`

  The `-mhtm` option enables a set of builtins making use of instructions available with the transactional execution facility introduced with the IBM zEnterprise EC12 machine generation S/390 System z Built-in Functions. `-mhtm` is enabled by default when using `-march=zEC12`.

`-mvx` ¶
`-mno-vx`

  When `-mvx` is specified, generate code using the instructions available with the vector extension facility introduced with the IBM z13 machine generation. This option changes the ABI for some vector type values with regard to alignment and calling conventions. In case vector type values are being used in an ABI-relevant context, a GAS ‘`.gnu_attribute`’ command is added to mark the resulting binary with the ABI used. `-mvx` is enabled by default when using `-march=z13`.

`-mzvector` ¶
`-mno-zvector`

  The `-mzvector` option enables vector language extensions and builtins using instructions available with the vector extension facility introduced with the IBM z13 machine generation. This option adds support for ‘`vector`’ to be used as a keyword to define vector type variables and arguments. ‘`vector`’ is only available when GNU extensions are enabled. It is not expanded when requesting strict standard compliance e.g. with `-std=c99`. In addition to the GCC low-level builtins, `-mzvector` enables a set of builtins added for compatibility with AltiVec-style implementations like Power and Cell. In order to make use of these builtins, you must include the header file `vecintrin.h`. `-mzvector` is disabled by default.

`-mmvcle` ¶
`-mno-mvcle`

  Generate (or do not generate) code using the `mvcle` instruction to perform block moves. When `-mno-mvcle` is specified, use a `mvc` loop instead. This is the default unless optimizing for size.

`-mdebug` ¶
`-mno-debug`

  Print (or do not print) additional debug information when compiling. The default is to not print debug information.

`-march=cpu-type` ¶

  Generate code that runs on cpu-type, which is the name of a system representing a certain processor type. Possible values for cpu-type are ‘`z900`’/‘`arch5`’, ‘`z990`’/‘`arch6`’, ‘`z9-109`’, ‘`z9-ec`’/‘`arch7`’, ‘`z10`’/‘`arch8`’, ‘`z196`’/‘`arch9`’, ‘`zEC12`’, ‘`z13`’/‘`arch11`’, ‘`z14`’/‘`arch12`’, ‘`z15`’/‘`arch13`’, ‘`z16`’/‘`arch14`’, ‘`z17`’/‘`arch15`’, and ‘`native`’.

  The default is `-march=z900`.

  Specifying ‘`native`’ as cpu type can be used to select the best architecture option for the host processor. `-march=native` has no effect if GCC does not recognize the processor.

`-mtune=cpu-type` ¶

  Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The list of cpu-type values is the same as for `-march`. The default is the value used for `-march`.

`-mtpf-trace` ¶
`-mno-tpf-trace`

  Generate code that adds (does not add) in TPF OS specific branches to trace routines in the operating system. This option is off by default, even when compiling for the TPF OS.

`-mtpf-trace-skip` ¶
`-mno-tpf-trace-skip`

  Generate code that changes (does not change) the default branch targets enabled by `-mtpf-trace` to point to specialized trace routines providing the ability of selectively skipping function trace entries for the TPF OS. This option is off by default, even when compiling for the TPF OS and specifying `-mtpf-trace`.

`-mmain` ¶

  For TPF OS target, use this option when linking to add the startup code and other linker options to produce a main object.

`-mfused-madd` ¶
`-mno-fused-madd`

  Generate code that uses (does not use) the floating-point multiply and accumulate instructions. These instructions are generated by default if hardware floating point is used.

`-mwarn-framesize=framesize` ¶

  Emit a warning if the current function exceeds the given frame size. Because this is a compile-time check it doesn’t need to be a real problem when the program runs. It is intended to identify functions hat most probably cause a stack overflow. It is useful for environments with limited stack size e.g. the Linux kernel.

  A value of zero disables this warning; that is the default.

`-mwarn-dynamicstack` ¶
`-mno-warn-dynamicstack`

  Emit a warning if the function calls `alloca` or uses dynamically-sized arrays. This is generally a bad idea with a limited stack size.

`-mstack-guard=stack-guard` ¶
`-mstack-size=stack-size`
`-mno-stack-guard`
`-mno-stack-size`

  If these options are enabled, the S/390 back end emits additional instructions in the function prologue that trigger a trap if the stack size is stack-guard bytes above the stack-size (remember that the stack on S/390 grows downward). If the stack-guard option is omitted the smallest power of 2 larger than the frame size of the compiled function is chosen.

  These options are intended to be used to help debugging stack overflow problems. The additionally emitted code causes only little overhead and hence can also be used in production-like systems without greater performance degradation.

  The given values have to be exact powers of 2 and stack-size has to be greater than stack-guard without exceeding 64k. In order to be efficient the extra code makes the assumption that the stack starts at an address aligned to the value given by stack-size.

  The `-mstack-guard=` option can only be used in conjunction with `-mstack-size=`. You can override these options on the command line with `-mno-stack-guard` and `-mno-stack-size`, respectively.

`-mhotpatch=pre-halfwords,post-halfwords` ¶

  If the hotpatch option is enabled, a “hot-patching” function prologue is generated for all functions in the compilation unit. The function label is prepended with the given number of two-byte NOP instructions (pre-halfwords, maximum 1000000). After the label, 2 * post-halfwords bytes are appended, using the largest NOP-like instructions the architecture allows (maximum 1000000).

  If both arguments are zero, hotpatching is disabled.

  This option can be overridden for individual functions with the `hotpatch` attribute.

`-mpic-data-is-text-relative` ¶
`-mno-pic-data-is-text-relative`

  When compiling for S/390 with `-fpic` or `-fPIC`, normally GCC emits code using relative addressing between code and data. However, for hotpatching it might be required to introduce new `.text` parts while using the existing `.data` and `.bss` sections. In this case, use `-mno-pic-data-is-text-relative` to force addressing through the GOT instead.

`-mstack-protector-guard=guard` ¶
`-mstack-protector-guard-record`

  Generate stack protection code using canary at guard. Supported locations are ‘`global`’ for a global canary or ‘`tls`’ for a per-thread canary in the TLS block (the default).

  Option `-mstack-protector-guard-record` results in the generation of section `__stack_protector_loc` containing pointers to all instructions which load the address of the global guard. Thus, this option has only an effect in conjunction with `-mstack-protector-guard=global`. The intended use is for the Linux kernel.

`-mindirect-branch=choice` ¶
`-mindirect-branch-jump=choice`
`-mindirect-branch-call=choice`
`-mfunction-return=choice`
`-mfunction-return-mem=choice`
`-mfunction-return-reg=choice`

  This group of options addresses security vulnerabilities related to speculative execution and indirect branch prediction by enabling replacement of indirect branches and function returns with direct branches to a thunk.

  Specifying a choice of ‘`keep`’ causes generation of the default code. ‘`thunk`’ triggers generation of out-of-line thunks and replaces the formerly indirect branch with a direct branch to the thunk. ‘`thunk-extern`’ does the branch replacement like ‘`thunk`’ but does not emit the thunks. ‘`thunk-inline`’ is only available with `-mindirect-branch-jump`; it should be used in preference to ‘`thunk`’ in user-space applications to support correct stack unwinding and exception handling.

  `-mindirect-branch` sets the value of `-mindirect-branch-jump` and `-mindirect-branch-call`. `-mfunction-return` sets the value of `-mfunction-return-reg` and `-mfunction-return-mem.`

  All of these options can also be set on a per-function basis using function attributes.

`-mindirect-branch-table` ¶
`-mno-indirect-branch-table`

  This option is useful in conjunction with the `-mindirect-branch` and `-mfunction-return` options. When enabled, it causes generation of tables pointing to the branch locations which have been patched by those options. The tables are emitted in sections named `.s390_indirect_jump`, `.s390_indirect_call`, `.s390_return_reg`, and `.s390_return_mem`. Each section consists of an array of 32-bit elements; each entry holds the offset from the entry to the patched location.

`-mfentry` ¶
`-mno-fentry`

  When used in conjunction with the `-pg` option, emit profiling code using the `__fentry__` hook provided by GLIBC 2.29 or later. This is only available for 64-bit code. If this option is not enabled, profiling uses the less efficient `_mcount` hook instead.

`-mrecord-mcount` ¶
`-mno-record-mcount`

  When enabled, generate a `__mcount_loc` section with the locations of all generated profiling calls to `_mcount` or `__fentry__`.

`mnop-mcount` ¶
`mno-nop-mcount`

  Instead of generating calls to `_mcount` or `__fentry__` with `-pg`, insert a sequence no-op instructions of the same length at the locations where the calls would have been inserted. This can be used in conjunction with the `-mrecord-mcount` option to patch the call sequences into the object file without recompiling it.

`-mpreserve-args` ¶
`-mno-preserve-args`

  When enabled, save all argument registers to the stack, and generate corresponding CFI information. This is useful for applications that want to implement their own stack unwinding and need access to function arguments.

`-munaligned-symbols` ¶
`-mno-unaligned-symbols`

  Assume that external symbols with a natural alignment of 1 are potentially unaligned. By default, all symbols without explicit alignment are assumed to be aligned on a 2-byte boundary as mandated by the IBM Z ABI.