602.gcc_s
SPEC CPU2017 Benchmark Description

Benchmark Name

602.gcc_s

Benchmark Author

Richard Stallman and a large cast of helpers.
For a full list, see http://gcc.gnu.org/onlinedocs/gcc/Contributors.html

Benchmark Program General Category

C Language optimizing compiler

Benchmark Description

602.gcc_s is based on GCC Version 4.5.0. It generates code for an IA32 processor. The benchmark runs as a compiler with many of its optimization flags enabled.

602.gcc_s has altered inlining heuristics, so as to inline more code than may be typical of Unix systems as of the time that the porting work was done for the benchmark. This was done so that 602.gcc_s would spend more time analyzing its source code inputs, and use more memory. Without this effect, 602.gcc_s would have done less analysis, and needed more input workloads to achieve the run times required for CPU2017. Recall that SPEC CPU benchmarks are drawn from 'the compute-intensive portion of real applications'; therefore, for the benchmark version, the preference is to compile a few large files instead of many small files.

Input Description

The inputs to the benchmark are C source code files. The large files for the ref workloads are GCC itself, after preprocessing. The presentation of the entire (preprocessed) source set at one time avoids I/O and allows the benchmark compiler a wide scope as it considers optimizations. There are several optimizations used, which can be found in the file control in each of the input directories. For example, the brief 'test' workload uses
-O3 -finline-limit=50000.

New inputs can be generated by writing C source code.

Output Description

All output files are IA32 assembly code files.

Programming Language

C

GNU C Portability Considerations: confusion from duplicate symbols

You may encounter errors such as the following when compiling the SPEC CPU2017 benchmark version of gcc. Read this section if you see symbol definitions errors such as:

   cc1-checksum.o: In function `vprintf':
   /usr/include/bits/stdio.h:38: multiple definition of `vprintf'
   main.o:/usr/include/bits/stdio.h:38: first defined here

Notice in the message above that the compiler appears to be objecting to using a definition at
stdio.h:38 because it already has a definition at
stdio.h:38.

That somewhat confusing error signature is due to inclusion of header files that use pre-1999 inlining keywords. See the documentation of -fgnu89-inline in the GNU chapter on C-Dialect-Options, and the associated discussion of inlining, which explains how the keywords inline, static, and extern were standardized in a manner that differs from their pre-1999 use by GCC.

The following table provides recommendations if you encounter the above error.

Data
Model
Workaround Comments
-m32 or -m64 -std=gnuNN
MAY CAUSE DIFFICULTY FOR OTHER BENCHMARKS

If you select a language dialect that enables GNU extensions, you may find that 602.gcc_s succeeds but other benchmarks fail.

Recall that SPEC's rules require that in 'base', all modules of a given language must use the same flags. You should pick a language dialect that works for all the benchmarks in the suite. (Note: using std=gnuXX as a "Portability" flag is not likely to be approved by SPEC, because the portabilty rule considers degree of impact. Setting a GNU-specific dialect as a portablility flag is not required given that more narrow solutions are available.)

-m64
intrate,intspeed=base:
LDCFLAGS = -z muldefs
RECOMMENDED

If compiling 64-bit, the recommendation is to allow multiple definitions. The linker uses the first definition that it sees, which is benign, because (for example) the routine at
stdio.h:38 happens to be identical to the routine at
stdio.h:38.

Note: as shown on the left, in base you would set the flag for all benchmarks. In peak, if you wish, you could be more selective and set it only for 602.gcc_s.

-m32 -z muldefs -D_FILE_OFFSET_BITS=64
WORTH TRYING

If you are compiling 32-bit, you can try -z muldefs -D_FILE_OFFSET_BITS=64. Perhaps it will work. Or, it may fail with messages from the GNU assembler as described below.

-m32 -z muldefs
(without mention of _FILE_OFFSET_BITS)
NOT RECOMMENDED

It is strongly recommended that 32-bit compiles should include -D_FILE_OFFSET_BITS=64, because at run-time, operations using modern file systems may fail spectacularly and frequently (or, worse, quietly and randomly) if a program does not accommodate 64-bit metadata.

-m32
intrate,intspeed=base:
PORTABILITY     = -D_FILE_OFFSET_BITS=64
EXTRA_COPTIMIZE = -fgnu89-inline
RECOMMENDED

As described just above, 32-bit compiles should include -D_FILE_OFFSET_BITS=64 in order to ensure that they run correctly on modern file systems. You may find that doing so leads to symptoms such as:

   filename: Assembler messages:
   filename:11843: Error: symbol `stat64' is already defined
   filename:11863: Error: symbol `lstat64' is already defined 

The above error occurs on certain paths through system header files that lead to GCC deciding that the code body needs to be included in the assembly routine -- twice. If this happens in your environment, a solution is -fgnu89-inline.

Note: as shown on the left, in base you would set the flag for all benchmarks. In peak, if you wish, you could be more selective and set it only for 602.gcc_s.

Other Portability Considerations

  1. Some of the optimizations 602.gcc_s performs require constant propagation of floating point constants. These form an insignificant amount of computation time, yet may depend on IEEE floating point format to produce a correct result.
  2. 602.gcc_s is not an ANSI C program. It uses GNU extensions.
  3. The initial port of 602.gcc_s was to a 64 bit system. It has been successfully ported by SPEC to many 32-bit UNIX implementations.

Sources and Licensing

602.gcc_s is based on the GNU C compiler version 4.5, using the GNU GPL license.

Please see details in the document SPEC CPU2017 Licenses.

References

Last updated: $Date: 2017-05-24 15:49:39 -0400 (Wed, 24 May 2017) $