ZCC Terapines LTD zcc(based on clang) Compiler Suite Flag Descriptions One or more of the following may have been used in the run. If so, it will be listed in the notes sections. Here is a brief guide to understanding them:

]]>
Compilers: Terapines LTD zcc(based on clang) Compiler Suite ]]>
/path/to/{zcc|z++|gfortran} Invokes the Terapines C compiler.

]]> Invokes the GNU Fortran compiler.

]]> z++ Invokes the Terapines C++ compiler.

]]> Place uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object. See also https://gcc.gnu.org/gcc-10/porting_to.html.

]]> Enable data locality Optimization When invoked with source code.

]]> -f-finite-math-only, -fno-finite-math-only ffinite-math-only, which is implied by -fast-math and -Ofast, allows optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. Setting -fno-finite-math-only does the opposite: the compiler must prepare for the possible presence of NaNs and infinities.

]]> Tells GCC to use the GNU semantics for "inline" functions, that is, the behavior prior to the C99 standard. This switch may resolve duplicate symbol errors, as noted in the 502.gcc_r benchmark description.

]]> Enable Link Time Optimization When invoked with source code, it generates GIMPLE (one of GCC's internal representations) and writes it to special ELF sections in the object file. When the object files are linked together, all the function bodies are read from these ELF sections and instantiated as if they had been part of the same translation unit.

]]> The language standards set aliasing requirements: programmers are expected to follow conventions so that the compiler can keep track of memory. If a program violates the requirements (for example, using pointer arithmetic), programs may crash, or (worse) wrong answers may be silently produced.

Unfortunately, the aliasing requirements from the standards are not always well understood.

Sometimes, the aliasing requirements are understood and nevertheless intentionally violated by smart programmers who know what they are doing, such as the programmer responsible for the inner workings of Perl storage allocation and variable handling.

The -fno-strict-aliasing switch instructs the optimizer that it must not assume that the aliasing requirements from the standard are met by the current program. You will probably need it for 500.perlbench_r and 600.perlbench_s. Note that this is an optimization switch, not a portability switch. When running SPECint2017_rate_base or SPECint2017_speed_base, you must use the same optimization switches for all the C modules in base; see https://www.spec.org/cpu2017/Docs/runrules.html#BaseFlags and https://www.spec.org/cpu2017/Docs/runrules.html#MustValidate.

]]> The switch -funsafe-math-optimizations allows the compiler to make certain(*) aggressive assumptions, such as disregarding the programmer's intended order of operations. The run rules allow such re-ordering https://www.spec.org/cpu2017/Docs/runrules.html#reordering. The rules also point out that you must get answers that pass SPEC's validation requirements. In some cases, that will mean that some optimizations must be turned off.

-fno-unsafe-math-optimizations turns off these(*) optimizations. You may need to use this flag in order to get certain benchmarks to validate. Note that this is an optimization switch, not a portability switch. If it is needed, then in base you will need to use it consistently. See: https://www.spec.org/cpu2017/Docs/runrules.html#BaseFlags and https://www.spec.org/cpu2017/Docs/runrules.html#MustValidate.

(*) Much more detail about which optimizations is available.

]]> -g Produce debugging information. -march=rv64gc, -march=athlon, -march=armv8.2-a+lse, -march=native... On x86 systems, allows use of instructions that require the listed architecture.

On Arm systems, specifies the name of the target architecture and, optionally, one or more feature modifiers. This option has the form -march=arch{+[no]feature}

]]> -mcpu=sifive-u74, -mcpu=neoverse-n1, -mcpu=niagara4, ... On aarch64 systems, mcpu sets the what kind of instructions can be used (as if by -march) and how to tune for performance (as if by -mtune).
On x86 systems, mcpu is a deprecated synonym for mtune.
On SPARC systems, mcpu sets the available instruction set.

]]> -mllvm --no-unsigned-wrap=false; Turn on/off no unsigned wrap optimization.

]]> -O1, -O2, -O3 Increases optimization levels: the higher the number, the more optimization is done. Higher levels of optimization may require additional compilation time, in the hopes of reducing execution time. At -O, basic optimizations are performed, such as constant merging and elimination of dead code. At -O2, additional optimizations are added, such as common subexpression elimination and strict aliasing. At -O3, even more optimizations are performed, such as function inlining and vectorization.
Many more details are available.

]]> Sets the language dialect to include syntax from the C99 standard, such as bool and other features used in CPU 2017 benchmarks.

]]> -std=c++03 Sets the language dialect to include syntax from the 1998 ISO C++ standard plus the 2003 technical corrigendum.

]]> --target=riscv64-unknown-linux-gnu, --target=riscv64-unknown-elf, --target=riscv32-unknown-elf, ... Specify the architecture to build for (all platforms)..

]]>