Advanced Optimization and New Capabilities of GCC 14

Often you will find that the system compiler perfectly satisfies your needs. After all, it is the compiler used to build the vast majority of packages and their updates in the system itself. On the other hand, there are situations where a newer compiler is necessary, or where you want to consider using a newer compiler to get some benefits of its ongoing development.

If the program or library you are building uses language features which are not supported by GCC 7, you cannot use the system compiler. However, the compiler from the Development Tools Module will usually be sufficiently new. The most obvious case is C++. GCC 14 has a mature implementation of C++17 features, whereas the one in GCC 7 is only experimental and incomplete. The GNU C++ Library which accompanies GCC 14 is also C++17 feature-complete.

Important: Code using C++17 features

Code using C++17 features should always be compiled with the compiler from the Development Tools Module. Linking two objects, such as an application and a shared library, both using C++17—where one is built with g++ 8 or earlier and the other with g++ 9 or later—is especially risky. This is because C++ STL objects instantiated by the experimental code may provide implementation and even ABI that is different from what the mature implementation expects and vice versa. Issues caused by such a mismatch are difficult to predict and may include silent data corruption.

Most of C++20 features are implemented in GCC 14 as experimental features. Try them out with appropriate caution and avoid linking together code that uses them and is produced by different compilers. Modules are only partially implemented ^[1] and require that the source file is compiled with -⁠fmodules-ts option. Similarly, coroutines ^[2] are also implemented but require that the source file is compiled with the -⁠fcoroutines switch. GCC 14 also experimentally implements many C++23 and some C++26 features. If you are interested in the implementation status of any particular C++ feature in the compiler or the standard library, consult the following pages:

Advances in supporting new language specifications are not limited to C++. GCC 14 experimentally supports most of the new features from the ISO C23 standard, and the Fortran compiler is also continuously improved. And if you use OpenMP or OpenACC extensions for parallel programming, you will find that the compiler supports a lot of features of new versions of these standards. For more details, visit the links at the end of this section.

In addition to new supported language constructs, GCC 14 offers improved diagnostics when it reports errors and warnings to the user so that they are easier to understand and to be acted upon. This is particularly useful when dealing with issues in templated C++ code. Furthermore, there are several new warnings which help to avoid common programming mistakes.

Because GCC 14 is newer, it can generate code for many recent processors not supported by GCC 7. Such a list of processors would be too large to be enumerated here. Nevertheless, in Section 7, “Performance evaluation: SPEC CPU 2017” we specifically look at optimizing code for AMD EPYC 9005 Series Processors which are based on AMD Zen 5 cores. The system compiler does not know this kind of core and therefore cannot optimize for it. On the other hand, GCC 14.2 can both detect and optimize for Zen 5.

Finally, the general optimization pipeline of the compiler has also significantly improved over the years. To find out more about improvements in versions of GCC 8 through 14, visit their respective “changes” pages:

GCC 14 from the Development Tools Module can sometimes behave differently in a way that can cause issues which were not present with the system compiler. Such problems encountered by other users are listed in the following documents:

To get an understanding of the problems, read through these pages, all but the last one are fairly short. The document at hand briefly mentions a few most common potential pitfalls.

Starting with GCC 14, the C compiler treats some situations which were never allowed since the 1999 revision ISO C as errors. In GCC 13 and before, the compiler only generated warnings for them:

We strongly recommend that you take the time to fix any of the above problems if you encounter them in your code. They have been a frequent source of bugs, portability and even security issues. More information about all of these cases together with the most common ways of addressing them are given in the “Porting to GCC 14” document referenced above. If the code is written in a version of C before the 1999 ISO standard, you can tell the compiler by using the -std=gnu89 or -std=c89 option, which will again allow those constructs. If your code uses features of this standard or a later one and for some reason it is not possible to fix it, you can either turn a specific class of the new errors back to warnings with a corresponding -⁠Wno-error= option or use a new compiler switch -⁠fpermissive to do so for all of the above.

Note: Impact on build environment probing

Many code snippets (also called probes) generated by autoconf to discover the availability of various features work in the way that they trigger a compile error when a feature is missing. The new errors may cause compilation to fail when it worked before and thus lead to features being silently disabled even when they are actually available. autoconf has supported C99 compilers since version 2.69 in its generic, core probes. However, earlier versions or very specific probes might rely on C features that were removed in C99 and thus fail with GCC 14. In cases where this is a concern, you can compare the generated config.log, config.h and other generated files using diff to ensure there are no unexpected differences.

The second common pitfall is that GCC 10 and later default to -⁠fno-common for performance reasons. This means a linker error will now be reported if the same variable is defined in two C compilation units. This can happen if two or more .c files include the same header file which intends to declare a variable but omits the extern keyword when doing so, inadvertently resulting in multiple definitions. If you encounter such an error, you need to add the extern keyword to the declaration in the header file and define the variable in only a single compilation unit. Alternatively, you can compile your project with an explicit -⁠fcommon if you are willing to accept that this behavior is inconsistent with C++ and may incur speed and code size penalties.

Users compiling C++ sources should also be aware that g++ version 11 and later default to -std=gnu++17, the C++17 standard with GNU extensions, instead of -std=gnu++14. Moreover, some C++ Standard Library headers have been changed to no longer include other headers that they do not depend on. You may need to explicitly include <limits>, <memory>, <utility> or <thread>.

The final issue emphasized here is that the C++ compiler in GCC 8 and later now assumes that no execution path in a non-void function reaches the end of the function without a return statement. This means it is assumed that such code paths will never be executed, and thus they will be eliminated. You should therefore pay special attention to warnings produced by -Wreturn-type. This option is enabled by default and indicates which functions are affected.

Similar to other modules and extensions for SUSE Linux Enterprise Server 15, you can activate the Development Tools Module using either the command line tool SUSEConnect or the YaST setup and configuration tool. To use the former, carry out the following steps:

If you prefer to use YaST, the procedure is also straightforward. Run YaST as root and go to the Add-On Products menu in the Software section. If “Development Tools Module” is among the listed installed modules, you already have the module activated and can proceed with installing individual compiler packages. If not, click the Add button, select Select Extensions and Modules from Registration Server, and YaST will guide you through a simple procedure to add the module.

When you have the Development Tools Module installed, you can verify that the GCC 14 packages are available to be installed on your system:.

sles15: # zypper search gcc14
Refreshing service 'Basesystem_Module_15_SP6_x86_64'.
Refreshing service 'Certifications_Module_15_SP6_x86_64'.
Refreshing service 'Containers_Module_15_SP6_x86_64'.
Refreshing service 'Desktop_Applications_Module_15_SP6_x86_64'.
Refreshing service 'Development_Tools_Module_15_SP6_x86_64'.
Refreshing service 'Python_3_Module_15_SP6_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP6_x86_64'.
Refreshing service 'SUSE_Package_Hub_15_SP6_x86_64'.
Refreshing service 'Web_and_Scripting_Module_15_SP6_x86_64'.
Loading repository data...
Reading installed packages...

S  | Name                     | Summary
---+--------------------------+----------------------------------------------------------
   | gcc14                    | The GNU C Compiler and Support Files
   | gcc14                    | The GNU C Compiler and Support Files
   | gcc14-32bit              | The GNU C Compiler 32bit support
   | gcc14-ada                | GNU Ada Compiler Based on GCC (GNAT)
   | gcc14-ada-32bit          | GNU Ada Compiler Based on GCC (GNAT)
   | gcc14-c++                | The GNU C++ Compiler
   | gcc14-c++-32bit          | The GNU C++ Compiler
   | gcc14-d                  | GNU D Compiler
   | gcc14-d-32bit            | GNU D Compiler
   | gcc14-fortran            | The GNU Fortran Compiler and Support Files
   | gcc14-fortran-32bit      | The GNU Fortran Compiler and Support Files
   | gcc14-go                 | GNU Go Compiler
   | gcc14-go-32bit           | GNU Go Compiler
   | gcc14-info               | Documentation for the GNU compiler collection
   | gcc14-locale             | Locale Data for the GNU Compiler Collection
   | gcc14-m2                 | GNU Modula-2 Compiler
   | gcc14-m2-32bit           | GNU Modula-2 Compiler
   | gcc14-obj-c++            | GNU Objective C++ Compiler
   | gcc14-obj-c++-32bit      | GNU Objective C++ Compiler
   | gcc14-objc               | GNU Objective C Compiler
   | gcc14-objc-32bit         | GNU Objective C Compiler
   | gcc14-PIE                | A default configuration to build all binaries in PIE mode
   | libquadmath0-devel-gcc14 | The GNU Fortran Compiler Quadmath Runtime Library Develop
   | libstdc++6-devel-gcc14   | Include Files and Libraries mandatory for Development

Now you can install the compilers for the programming languages you use with zypper:

sles15: # zypper install gcc14 gcc14-c++ gcc14-fortran

The compilers are installed on your system, the executables are called gcc-14, g++-14, gfortran-14 and so forth. It is also possible to install the packages in YaST. To do so, enter the “Software Management” menu in the Software section and search for “gcc14”. Then select the packages you want to install. Finally, click the Accept button.

Note: Newer compilers on openSUSE Leap 15.6

The community distribution openSUSE Leap 15.6 shares the base packages with SUSE Linux Enterprise Server 15 SP6. The system compiler on systems running openSUSE Leap 15.6 is also GCC 7.5. There is no Development Tools Module for the community distribution available, but a newer compiler is provided. Install the packages gcc14, gcc14-c++, gcc14-fortran, and the like.

Applications built with LTO are often faster, mainly because the compiler can inline calls to functions in another compilation unit. This possibility also allows programmers to structure their code according to its logical division because they are not forced to put function definitions into header files to enable their inlining. Since the compiler cannot inline all calls conveying information known at compilation time, GCC tracks and propagates constants, value ranges, memory reference information and devirtualization contexts from the call sites to the callees, even when passed in an aggregate or by reference. These can then subsequently save unnecessary computations or enable subsequent optimizations and speed up the built program or library. LTO allows such propagation across compilation unit boundaries, too.

Link Time Optimization with whole program analysis also offers many opportunities to shrink the code size of the built project. Thanks to symbol promotion and inter-procedural unreachable code elimination, functions and their parts which are not necessary in any particular project can be removed even when they are not declared static and are not defined in an anonymous namespace. Automatic attribute discovery can identify C++ functions that do not throw exceptions. This allows the compiler to avoid generating a lot of code in exception cleanup regions. Identical code folding can find functions with the same semantics and remove all but one of them. The code size savings are often very significant and a compelling reason to use LTO even for applications which are not CPU-bound.

Note: Building libraries with LTO

The symbol promotion is controlled by resolution information given to the linker and depends on type of the DSO build. When producing a dynamically loaded shared library, all symbols with default visibility can be overwritten by the dynamic linker. This blocks the promotion of all functions not declared inline, thus it is necessary to use the hidden visibility wherever possible to achieve best results. Similar problems happen even when building static libraries with -rdynamic.

As mentioned earlier, the vast majority of packages in the openSUSE Tumbleweed distribution are built with LTO by default and work fine without any tweaks. Nevertheless, some low-level constructs pose a problem for LTO. One typical issue are symbols defined in inline assembly which can happen to be placed in a different partition from their uses and subsequently fail the final linking step. To build such projects with LTO, the assembler snippets defining symbols must be placed into a separate assembler source file so that they only participate in the final linking step. Global register variables are not supported by LTO, and programs either must not use this feature or be built the traditional way. You can also exclude some compilation units from LTO (by compiling them without -⁠flto or appending -⁠fno-⁠lto to the compilation command line), while the rest of the program can still benefit from using this feature.

Another notable limitation of LTO is that it does not support symbol versioning implemented with special inline assembly snippets (as opposed to a linker map file). To define symbol versions in the source files, you can do so with the symver function attribute. As an example, the following snippet will make the function foo_v1 implement foo in node VERS_1 (which must be specified in the version script supplied to the linker). Consult the manual for more details.

__attribute__ ((__symver__ ("foo@VERS_1")))
int foo_v1 (void)
{
}

Sometimes the extra power of LTO reveals pre-existing problems which do not manifest themselves otherwise. Violations of (strict) aliasing rules and C++ one definition rule tend to cause misbehavior significantly more often. The latter is fortunately reported by the -Wodr warning which is on by default and should not be ignored. We have also seen cases where the use of the flatten function attribute led to unsustainable amount of inlining with LTO. Furthermore, LTO is not a good fit for code snippets compiled by configure scripts (generated by autoconf) to discover the availability of various features, especially when the script then searches for a string in the generated assembly.

Finally, we needed to configure the virtual machines building the biggest openSUSE packages to have more memory than when not using LTO. Whereas in the traditional mode of compilation 1 GB of RAM per core was enough to build Mozilla Firefox, the serial step of LTO means the build-bots need 16 GB even when they have fewer than 16 cores.

In Section 3, “Optimization levels and related options” we recommend that HPC workloads are compiled with -⁠O3 and benchmarks with -⁠Ofast. But it is still interesting to look at integer crunching benchmarks built with only -⁠O2 because that is how Linux distributions often build the programs from which they were extracted. We have already mentioned that almost the whole openSUSE Tumbleweed distribution is now built with LTO, and selected packages with PGO, and the following paragraphs demonstrate why.

Figure 3: Overall performance (bigger is better) of SPEC INTrate 2017 built with GCC 14.2 and -⁠O2 #

  

Figure 3 shows the overall performance effect on the whole integer benchmark suite as captured by the geometric mean of all individual benchmark rates. Employing both PGO and LTO results in remarkable relative uplift of 16.5%. That is despite the fact that starting with GCC 12, the compiler can conservatively auto-vectorize code in 525.x264_r also at plain -⁠O2, whereas previously it was only automatically performed with PGO at this level. Nevertheless, this benchmark still benefits a lot from the more advanced modes of compilation, together with several others which are derived from programs that are typically compiled with -⁠O2. This is illustrated in figure 4.

Figure 4: Runtime performance (bigger is better) of individual integer benchmarks built with GCC 14.2 and -⁠O2 #

  

Figure 5 shows another important advantage of LTO and PGO which is significant reduction of the size of the binaries (measured without debug info). Note that it does not depict that the size of benchmark 548.exchange2_r grew to 260% and 174% of the original size when built with PGO or both PGO and LTO respectively, which looks huge but the growth is from a particularly small base. It is the only Fortran benchmark in the integer suite and, most importantly, the size penalty is offset by significant speed-up, making the trade-off reasonable. For completeness, we show this result in figure 6

Figure 5: Binary size (smaller is better) of individual integer benchmarks built with GCC 14.2 and -⁠O2 #

  

Figure 6: Binary size (smaller is better) of 548.exchange2_r built with GCC 14.2 and -⁠O2 #

  

The runtime benefits and binary size savings are also easily visible when using the optimization level -⁠Ofast and option -⁠march=native to allow the compiler to take full advantage of all instructions that the AMD EPYC 9755 Processor supports. Figure 7 shows the respective geometric means, and figure 8 shows how rates change for individual benchmarks. Even at the aggressive optimization level PGO brings about clear benefits for benchmarks derived from interpreters and compilers like 500.perlbench_r and 502.gcc_r but the compiler can struggle to correctly update the measured profile information when performing complex inter-procedural optimizations like in the case of 548.exchange2_r leading to the technique actually decreasing performance. Lastly, even though optimization levels -⁠O3 and -⁠Ofast are permitted to be relaxed about the final binary size, PGO and especially LTO can bring it nicely down at these levels, too. Figure 9 depicts the relative binary sizes of all integer benchmarks.

Figure 7: Overall performance (bigger is better) of SPEC INTrate 2017 built with GCC 14.2 using -⁠Ofast and -⁠march=native #

  

Figure 8: Runtime performance (bigger is better) of individual integer benchmarks built with GCC 14.2 using -⁠Ofast and -⁠march=native #

  

Figure 9: Binary size (smaller is better) of SPEC INTrate 2017 built with GCC 14.2 using -⁠Ofast and -⁠march=native #

  

Many of the SPEC 2017 floating-point benchmarks measure how well a given system can optimize and execute a handful of number crunching loops. They often come from performance sensitive programs written with traditional compilation method in mind. As a result, there are fewer cross-module dependencies, making the identification of hot paths less critical. Consequently, the overall impact of LTO and PGO on the suite is often minimal. Nevertheless, there are important cases when these modes of compilation also bring about significant performance increases. Figure 10 shows the effect of these methods on individual benchmarks when compiled at -⁠Ofast and targeting the full ISA of the AMD EPYC 9755 Processor. Furthermore, binary size savings of PGO and LTO are sometimes even bigger than those achieved on integer benchmarks, as can be seen in figure 11

Unfortunately, in the case of 538.imagick_r benchmark there is a big mismatch in between the code paths exercised in the train run which is used to measure which parts of the program need to be optimized for speed and the actual reference run which is then used to obtain the benchmark score. This is exactly the problem we warn against in Section 6, “Profile-Guided Optimization (PGO)” and it has the predictable detrimental effect on performance.^[5] Moreover, because the important loop, which is not appropriately optimized because it is not executed in the train run, is in a function in which there is another loop which is heavily executed in the train run, even using the -⁠fprofile-partial-training does not help to mitigate the problem. This is a bug in the SPEC CPU suite and it means that the overall performance score even decreases by 1% when using both LTO and PGO.

Figure 10: Runtime performance (bigger is better) of individual floating-point benchmarks built with GCC 14.2 using -⁠Ofast and -⁠march=native #

  

Figure 11: Binary size (smaller is better) of SPEC FPrate 2017 built with GCC 14.2 using -⁠Ofast and -⁠march=native #

  

In previous sections we have recommended the use of GCC 14.2 from the Development Tools Module over the system compiler. Among other reasons, we did so because of its more powerful optimization pipeline and its support for newer CPUs. This section compares SPEC CPU 2017 built with GCC 7.5, the system compiler in SUSE Linux Enterprise Server 15, and GCC 14.2 on an AMD EPYC 9755 Processor, when all benchmarks are compiled with -⁠Ofast and -⁠march=native. Note that the latter option means that both compilers differ in their CPU targets because GCC 7.5 does not know the Zen 5 core. This in turn means that in large part the optimization benefits presented here exist because the old compiler only issues 128bit (AVX2) vector operations whereas the newer one can take full advantage of AVX512. Nevertheless, be aware that using wider vectors everywhere often backfires. GCC has made substantial advancements over the recent years to avoid such issues, both in its vectorizer and other optimizers. It is therefore much better placed to use the extra vector width appropriately and produce code which utilizes the processor better in general.

Figure 12: Overall performance (bigger is better) of SPEC INTrate 2017 built with GCC 7.5 and 14.2 (-⁠Ofast -⁠march=native) #

  

Figure 12 captures the benefits of using the modern compiler with integer workloads in the form of relative improvements of the geometric mean of the whole SPEC INTrate 2017 suite. Figure 13 dives deeper and shows which particular benchmarks gained most in terms of performance. It was already mentioned that 525.x264_r especially benefits from vectorization and therefore it is not surprising it has improved a lot. 531.deepsjeng_r is faster chiefly because it can emit better code for count trailing zeros (CTZ) operation which it performs frequently. Finally, modern GCC can optimize 548.exchange2_r particularly well by specializing different invocations of the hottest recursive function and it also clearly shows in the picture.

Figure 13: Runtime performance (bigger is better) of selected integer benchmarks built with GCC 7.5 and 14.2 (-⁠Ofast -⁠march=native) #

  

Floating-point computations tend to particularly benefit from vectorization advancements. Thus it should be no surprise that the FPrate benchmarks also improve substantially when compiled with GCC 14.2, which also emits AVX512 instructions for a Zen 5 based CPU. The overall boost is shown in figure 14 whereas figure 15 provides a detailed look at which benchmarks contributed most to the overall score difference.

Figure 14: Overall performance (bigger is better) of SPEC FPrate 2017 built with GCC 7.5 and 14.2 (-⁠Ofast -⁠march=native) #

  

Figure 15: Runtime performance (bigger is better) of selected floating-point benchmarks built with GCC 7.5 and 14.2 (-⁠Ofast -⁠march=native) #

  

In Section 3, “Optimization levels and related options”, we highlighted that if you do not relax the semantics of floating-point math functions, despite not needing strict adherence to all IEEE and/or ISO rules, you are likely to sacrifice some performance. This section uses the SPEC FPrate 2017 test suite to illustrate how much performance that might be.

We have built the benchmarking suite using optimization level -⁠O3, LTO (though without PGO) and -⁠march=native to target the native ISA of our AMD EPYC 9755 Processor. Then we compared its runtime score against the suite built with these options and -⁠ffast-math. As you can see in figure 16, the geometric mean grew by over 13%. But a quick look at figure 17 will tell you that there are four benchmarks with scores which improved by more than 15% and that of 538.imagick_r grew by over 60%.

Figure 16: Overall performance (bigger is better) of SPEC FPrate 2017 built with GCC 14.2 and -⁠O3 -⁠flto -⁠march=native, without and with -⁠ffast-math #

  

Figure 17: Runtime performance (bigger is better) of individual floating-point benchmarks built with GCC 14.2 and -⁠O3 -⁠flto -⁠march=native, without and with -⁠ffast-math #

  

The toolchain team at SUSE regularly uses the SPEC CPU 2017 suite to compare the optimization capabilities of GCC with other compilers, mainly LLVM/Clang and ICX from Intel. In the final section of this case study, we will discuss how the Development Module compiler compares to its competitors on SUSE Linux Enterprise Server 15 SP6. Before we begin, it is important to note that the comparison was conducted by individuals with significantly more expertise in GCC than in the other compilers, and they are not completely “unbiased”. Also, keep in mind that everything we explained previously about how we carry out the measurements and patch the benchmarks also applies to this section. However, since the results inform our own work, rest assured that we strive for accuracy.

We have built the clang, clang++ and flang-new compilers from sources obtained from the official git repository (tag llvmorg-19.1.4), used it to compile the SPEC CPU 2017 suite with -⁠Ofast and -⁠march=native and compared the performance against the suites built with GCC 14.2 with the same options. When using Clang's LTO to compile SPEC, we selected the full variant because it is more powerful in terms of optimization capabilities even though it is not suitable for building large projects.

Figure 18: Overall performance (bigger is better) of C/C++ integer benchmarks built with Clang 19 and GCC 14.2 #

  

Figure 18 shows that the geometric mean of the whole SPEC INTrate 2017 suite is quite substantially better when the benchmarks are compiled with GCC. To be fair, a disproportionate amount of the difference is because GNU Fortran can optimize 548.exchange2_r much better than LLVM (see figure 18). Given that the LLVM Fortran front-end is relatively new and the optimization opportunities in this particular benchmark are quite specific, the result may not be relevant for many users.

Figure 19: Runtime performance (bigger is better) of 548.exchange2_r benchmarks built with Clang 19 and GCC 14.2 #

  

Figure 20: Runtime performance (bigger is better) of C/C++ integer benchmarks built with Clang 19 and GCC 14.2 #

  

Figure 20 shows relative rates of integer benchmarks written in C/C++ and the compilers perform fairly similarly there. GCC wins by a significant margin on 505.mcf_r, 531.deepsjeng_r and 500.perlbench_r but clearly loses when compiling 525.x264_r. This is because the compiler chooses a vectorizing factor that is too large for the important loops in this video encoder. It is possible to mitigate the problem using compiler option -⁠mprefer-⁠vector-⁠width=128, with which it is only 9% slower than Clang/LLVM, as you can see in figure 21. Another option yielding similar runtime of the benchmark is to use masked vectorized epilogues by passing option –⁠param vect-partial-vector-usage=1 to the compiler. Note that PGO can substantially help in this case too. The upcoming version, GCC 15, aims to solve the problem without a need for extra options by producing multiple cascading vector epilogues.

Figure 21: Runtime performance (bigger is better) of 525.x264_r benchmark built with Clang 19 and with GCC 14.2 using -mprefer-vector-width=128 #

  

The comparison of geometric mean of scores of SPEC FPrate 2017 suite when built with the two compiler suites is depicted in figure 22. The floating point benchmark suite includes many more Fortran benchmarks, and it is clear that GCC has an advantage in having a mature optimization pipeline for this language. This is particularly evident when compiling 503.bwaves_r, 519.lbm_r and 527.cam4_r (see figure 23). The comparison of performance of individual benchmarks also shows that the performance of 538.imagick_r is substantially bigger when compiled with GCC 14.2 while Clang/LLVM has an edge when optimizing 508.namd_r and 544.nab_r.

Figure 22: Overall performance (bigger is better) of SPEC FPrate 2017 built with Clang 19 and GCC 14.2 #

  

Figure 23: Runtime performance (bigger is better) of floating point benchmarks built with Clang 19 and GCC 14.2 #

  

Although Intel compilers are not designed for AMD processors, they are well-known for their high-level optimization capabilities, particularly in vectorization. Therefore, we have traditionally included ICC in our comparisons of compilers. Recently, however, Intel decided to discontinue this compiler and redirect its users toward ICX, a new compiler built on top of LLVM. In consequence, we have also shifted our focus to ICX. To keep the amount of data presented in this section manageable, we will focus on comparing only binaries built with LTO -⁠Ofast and -⁠march=native.

Figure 24: Overall performance (bigger is better) of SPEC INTrate 2017 built with ICX 2025.0.1 and GCC 14.2 #

  

Figure 24 shows that the new ICX compiler takes the lead in overall SPEC INTrate assessment. The results of individual benchmarks (see figure 25), however, illustrate that the majority of the lead is due to one benchmark, 525.x264_r, and for the same reasons we outlined when discussing LLVM/Clang results. GCC picks too large vectorizing factor and the mitigation is again using -⁠mprefer-⁠vector-⁠width=128 which leads to a much narrower gap (see figure 26). When looking at the other benchmarks (see figure 25), GCC achieves comparable results. In fact, if we excluded benchmark 525.x264_r from the computations of the geometric means, GCC would achieve a slightly better score than ICX in the LTO case. At this point we want to re-iterate that the next version of GCC aims to solve this problem without a need for extra compiler options.

Figure 25: Runtime performance (bigger is better) of individual integer benchmarks built with ICX 2025.0.1 and GCC 14.2 #

  

Figure 26: Runtime performance (bigger is better) of 525.x264_r benchmark built with ICX 2025.0.1 and with GCC 14.2 using -mprefer-vector-width=128 #

  

If we look at the geometric means that the two compilers can achieve when they are used to build SPEC FPrate suite, GCC wins by 17% or 19% without and with LTO respectively (see figure 27). Even in this case it is important to look at individual results though as the overall picture is more nuanced (see figure 28). There are benchmarks where GCC is much better (most prominently 538.imagick_r and 554.roms_r) but there are also those where the competition produces considerably faster code (especially 519.lbm_r and 544.nab_r). Nevertheless, the conclusion is that GCC manages to perform consistently and competitively against these high-performance compilers.

Figure 27: Overall performance (bigger is better) of SPEC FPrate 2017 built with ICX 2025.0.1 and GCC 14.2 #

  

Figure 28: Runtime performance (bigger is better) of individual floating point benchmarks built with ICX 2025.0.1 and GCC 14.2 #