GCC supports a -march switch that allows you to specify the architecture you are targeting - allowing it to tune instruction sequences for that platform as well as using instructions that might be available on the platform which aren't available on the "default" or base version of the architecture.
For example, -march=skylake will tell the compiler to target Skylake CPUs, including using instruction sets available on Skylake such as AVX2.
How can I tell what values for -march the local version of gcc supports? Newer versions helpfully list the valid arguments when an invalid argument is passed, but older versions do not.
With gcc7 and later, gcc will print the values it supports as part of the error message.
$ gcc -E -march=help -xc /dev/null
# 1 "/dev/null"
cc1: error: bad value (‘help’) for ‘-march=’ switch
cc1: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 bonnell atom silvermont slm knl x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2
I checked on Godbolt, and x86 gcc6.x and earlier just say error: bad value (invalid) for -march= switch even with -v.
It also doesn't work with clang5.0 or ICC18.
This is target-specific: ARM gcc6.3 does produce a list of supported -march values, or -mcpu=.
For gcc-7.2.0, it's here:
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/x86-Options.html#x86-Options
You could go to gcc online documentation. Then, find the manual for the version you are interested. Following that, go to machine dependent options section. If you are looking into x86, jump to the "x86 options" section. Now, search "-march."
I haven't checked the old gcc versions. Another way you could try is to check out the source code, and open the source code that keeps the literal strings for the supported arch.
svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_trunk
cd gcc_trunk
Then, maybe, you could try like this:
find . -type f | egrep "*\.(c|cc|cpp|h|hpp)$" | xargs egrep '"skylake-avx'
As of today, the literal strings are kept in ./gcc/config/i386/i386.c in case of x86 architectures.
%P.S.
As Peter mentioned, it seems machine-specific. I suspect that there isn't a standard/desired behavior that lists available march values. For example, if gcc has been just ported to a brand-new instruction set architecture, LEG--as opposed to ARM--, it does not necessarily have a command-line option to list all supported march values.
Fortunately, it seems like some newer gcc versions provide a way to do so. If you do need such an option for old gccs, writing a gcc plugin, which might work from gcc 4.5 or so, could be taken into consideration:
gcc plugin
simple gcc plugin how to
Gcc plugins are plugged-in to an existing gcc by adding some command-line options. Gcc has APIs for plugins. All you need would be to write a code that checks the information such as gcc version, the arch that runs gcc, etc, and that prints out the list of the supported march.
Use the detailed help page:
gcc -v --help
Look for the option -march=CPU, for example in gcc v4.8.4
-march=CPU[,+EXTENSION...]
generate code for CPU and EXTENSION, CPU is one of:
generic32, generic64, i386, i486, i586, i686,
pentium, pentiumpro, pentiumii, pentiumiii, pentium4,
prescott, nocona, core, core2, corei7, l1om, k1om,
k6, k6_2, athlon, opteron, k8, amdfam10, bdver1,
bdver2, bdver3, btver1, btver2
EXTENSION is combination of:
8087, 287, 387, no87, mmx, nommx, sse, sse2, sse3,
ssse3, sse4.1, sse4.2, sse4, nosse, avx, avx2,
avx512f, avx512cd, avx512er, avx512pf, noavx, vmx,
vmfunc, smx, xsave, xsaveopt, aes, pclmul, fsgsbase,
rdrnd, f16c, bmi2, fma, fma4, xop, lwp, movbe, cx16,
ept, lzcnt, hle, rtm, invpcid, clflush, nop, syscall,
rdtscp, 3dnow, 3dnowa, padlock, svme, sse4a, abm,
bmi, tbm, adx, rdseed, prfchw, smap, mpx, sha,
clflushopt, xsavec, xsaves, prefetchwt1
Since GCC 4 there's a --target-help which prints the supported parameters for options including
-march
-mtune
-mabi
-masm
Other options which themselves are architecture-specific e.g. -msse2, -mavx2
Related
For x86-64 there are lots of instruction sets that speed up code execution. Here is a list from gcc wiki https://gcc.gnu.org/wiki/FunctionMultiVersioning:
MMX
SSE
SSE2
SSE3
SSSE3
SSE4.1
SSE4.2
POPCNT
AVX
AVX2
For gcc compiler, what x86-64 instruction set does gcc target when you compile without any flags versus -O2?
To keep things simple lets just say the question is about gcc version 12 (most recent major). But I would like to know what gcc command switches/options i need to do to so that i can see what my version of gcc version does.
I assume that gcc chooses something that is "portable" so that would mean probably something slow. But this is just my assumption... I would like to know does that mean like SSE4.2 or none?
If you don't pass a command-line -march option, then you get whatever was selected when gcc was compiled. The default is -march=x86-64 but it could have been overridden by whoever compiled your gcc (e.g. your binary package distributor). See https://gcc.gnu.org/install/configure.html and note the --with-arch option.
You can compile with -v -Q to see what option is in use. Look for the options passed line.
With -march=x86-64 you get "least common denominator" code that will run on every known x86-64 CPU, all the way back to the AMD K8. This includes SSE2, which was part of the original AMD64 spec, but not SSE3 or anything later. popcnt would not be included either.
The -march option is orthogonal to optimization options like -O2 and the -f... flags (e.g. -funroll-loops). You always get code compatible with whatever is selected by -march, no matter what optimization options are in use. However -m flags (like -mavx) can permit the use of other CPU features beyond what -march implies, in which case your code is only guaranteed to run on CPUs with those features.
I have been tweaking GCC 6.3.0 to get it to use the libc++ runtime instead of libstdc++ so that g++ can be used without worrying about C++ runtime incompatibilities:
https://github.com/RJVB/macstrop/tree/master/lang/gcc6
The tweak works, I can build and run KDE software using g++ against Qt5 and KF5 frameworks (and everything else) built with various clang versions.
What doesn't work is generating code that uses AVX and presumably most or all newer intrinsic instructions.
This is not a new issue that's never been invoked on here; it's answered here for instance: How to use AVX/pclmulqdq on Mac OS X
Evidently one can configure gcc to call the linked script instead of the actual as executable.
But can gcc not be configured to use another assembler altogether, like nasm, and would that solve this issue?
According to the address-sanitizer home page it comes only with the gcc 4.8 or above. Isn't there anyway of using it with gcc 4.7?
No, there is no reliable way (to get ASAN before GCC 4.8). ASAN requires compiler support and is very intimately connected to your particular compiler (and version, and host and target systems, and specific configuration, etc...)
In other words, try to compile a recent GCC (that is, GCC 5.2 in july 2015; use that since ASAN did progress since 4.8 and you'll get more -fsanitize= options in recent versions of GCC) from its downloaded source code. See hints here & there. You should try some recent Linux distribution.
(on Linux or other POSIX systems, you don't need root privileges to configure, compile, and install gcc-mine-5 in $HOME/soft/; you need appropriate ../gcc-5.2/configure options, notably --prefix=$HOME/soft --program-suffix=-mine-5, then add $HOME/soft/bin/ in your PATH then run with CC=gcc-mine-5 e.g. for make)
I'm trying to build a binary with GCC 4.9.0 that is backwards-compatible against libstdc++. According to GCC's ABI Policy and Guidelines and Options Controlling C++ Dialect, the command line option -fabi-version should do the trick; however, no matter which version I set, I still get imports of symbols from a version newer then desired, like this:
$ objdump -T binary | grep GLIBCXX_3.4.20
00000000 DF *UND* 00000000 GLIBCXX_3.4.20 _ZSt24__throw_out_of_range_fmtPKcz
I've tried -fabi-version=1 to -fabi-version=5 (ABI version 5 corresponds to GCC 4.6, which is guaranteed to be present on the target system), but those imports keep winding up in the resulting files.
How do I fix this? Going back to an old GCC version is not an option to me for other reasons.
the command line option -fabi-version should do the trick
No, that's completely unrelated to what you want. That option affects the code generated by the compiler, it does not mean you can link to an older version of libstdc++ (which is what you would need in order to stop depending on symbols in the newer libstdc++).
You cannot link to an older libstdc++ with a new GCC. The version of libstdc++ is tightly coupled to the version of GCC, so if you want to linker to an older libstdc++ then you need to compile with an older GCC.
You cannot tell libstdc++ to not use the new symbols, the reason it depends on them is because it needs them. Use an older libstdc++.
Going back to an old GCC version is not an option to me for other reasons.
Then you're screwed.
You either need to use an older GCC, or not link dynamically to libstdc++.so.
On Red Hat Enterprise Linux or CentOS you would have the option of using a newer GCC from the Developer Toolset which avoids linking to the new libstdc++.so but that is only compatible with the system GCC, which is GCC 4.4 for RHEL6 or GCC 4.7 for RHEL7. You can't use it to be compatible with GCC 4.6.
I am trying to compile a program that uses the pclmulqdq instruction present in new Intel processors. I've installed GCC 4.6 using macports but when I compile my program (which uses the intrinsic _mm_clmulepi64_si128), I get
/var/folders/ps/sfjmtgx5771_qbqnh4c9xclr0000gn/T//ccEAWWhd.s:16:no such
instruction: `pclmulqdq $0, %xmm0,%xmm1'
It seems that GCC is able to generate the correct assembly code from the instrinsic, but the assembler does not recognize the instruction.
I've installed binutils using macports, but the problem persists. How do I know which assembler gcc is using? The XCode assembler probably does not support it, but the binutils assembler should.
A simpler solution that fixed this problem for me was adding -Wa,-q to the compiler flags. From the man pages for as (version 1.38):
-q
Use the clang(1) integrated assembler instead of the GNU based system assembler.
The -Wa part passes it from the compiler driver to the assembler, much like -Wl passes arguments to the linker.
The GNU assembler (GAS) is not supported in Mac OS X.
In order to use AVX, I had to:
Install GCC using MacPorts;
Replace the native OS X assembler (/usr/bin/as) by a script which calls the clang assembler.
Compile the program with the installed GCC (e.g. gcc-mp-4.7)
The strange thing is that while the clang assembler supports AVX, the clang compiler does not recognize the AVX instrinsics, forcing the ugly workaround above.
The built in version of as is outdated. (In OS X 10.8.3)
/usr/libexec/as/x86_64/as -v
Apple Inc version cctools-839, GNU assembler version 1.38
There does not seem to exist a version of gas for OS X. (See:
Installing GNU Assembler in OSX)
Using the clang assembler via a script hack (as pointed out by Conrado PLG) is one workaround. However, it does require administrator privileges and overwrites OS X-bundled executables, causing a risk of it being overwritten by a new (yet possibly outdated) version of as bundled with a future version of OS X.
Is there then a better workaround?
As noted on Why does cross gcc invoke native 'as'? it seems to be possible to specify which "as"-executable and flags to use (using "-specs=..."). A cleaner workaround to the problem seems to be to pass the correct "-specs" flags to invoke the clang assembler. This does not require admin privileges and does not risk being broken by an OS X update. The exact details of how to perform this remains to be found out (anyone?).
If this workaround becomes trouble-free and transparent enough, it may be warranted to use those settings as a default (or at least variant) for the macport gcc (so that it supports "-march=native" and the like). There is such as configure.args setting ("--with-as=${prefix}/bin/as", as seen in https://trac.macports.org/browser/trunk/dports/lang/gcc48/Portfile ), which could be replaced.
Just use
as --version
AVX appeared around version 2.18.50 in gas/binutils.
It appears that I fixed my issue by using the gcc / asm syntax where asm{} function is passed a string consisting of assembler statements surrounded by quotes and separated by a backslash and newline or backslash and quoted string containing another assembler statement.
https://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s3