[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-08 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #7 from H.J. Lu --- -march=native overrides everything, including, -march= after it: [hjl@gnu-cfl-2 gcc]$ cat /tmp/foo.c #ifndef __AVX512F__ # error No AVX512F #endif [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -march=skylake-avx512 -S /tmp/foo.c [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -march=native -march=skylake-avx512 -S /tmp/foo.c /tmp/foo.c:2:3: error: #error No AVX512F 2 | # error No AVX512F | ^ [hjl@gnu-cfl-2 gcc]$
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #6 from Thiago Macieira --- Clang is not affected: $ clang -dM -E -xc /dev/null -march=sandybridge -march=native | grep AVX #define __AVX2__ 1 #define __AVX__ 1 $ clang -dM -E -xc /dev/null -march=native -march=sandybridge | grep AVX #define __AVX__ 1 Instead of enabling the CPU features your CPU has, Clang tries to guess which CPU you have and will apply it. This has side-effects for non-arch-specific items like AES. ICC is similarly affected, despite claiming it isn't: $ icc -dM -E -xc /dev/null -march=sandybridge -march=native | grep AVX icc: command line warning #10121: overriding '-march=sandybridge' with '-march=native' icc: command line warning #10121: overriding '-march=sandybridge' with '-march=native' #define __AVX_I__ 1 #define __AVX__ 1 #define __AVX2__ 1 $ icc -dM -E -xc /dev/null -march=native -march=sandybridge | grep AVX icc: command line warning #10121: overriding '-march=native' with '-march=sandybridge' #define __AVX_I__ 1 #define __AVX__ 1 #define __AVX2__ 1 It says it's overriding, but doesn't override.
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 Thiago Macieira changed: What|Removed |Added CC||thiago at kde dot org --- Comment #5 from Thiago Macieira --- Same thing here. User passes CFLAGS="-march=native" for their system, but library needs to build one .cpp source with -march=haswell for additional functionality (runtime-checked via CPUID). Unfortunately, -march=native supersedes all other -march options, regardless of order, unlike all other options. Examples: $ gcc -dM -E -xc /dev/null -march=sandybridge -march=haswell | grep AVX #define __AVX__ 1 #define __AVX2__ 1 $ gcc -dM -E -xc /dev/null -march=haswell -march=sandybridge | grep AVX #define __AVX__ 1 $ gcc -dM -E -xc /dev/null -march=sandybridge -march=native | grep AVX #define __AVX__ 1 #define __AVX2__ 1 $ gcc -dM -E -xc /dev/null -march=native -march=sandybridge | grep AVX #define __AVX__ 1 #define __AVX2__ 1 Qt is affected: https://bugreports.qt.io/browse/QTBUG-71564. The problem began when we switched from appending -mavx2 to appending -march=haswell, so we'd get FMA and BMI1/2 in the same file.
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #4 from wavexx at thregr dot org --- Since I couldn't find documentation for it either, doesn't -march=haswell by itself imply all associated ISA features? If so, why -march=native expands to all individual features explicitly?
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #1 from Jonathan Wakely --- Some discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg0.html However ... (In reply to wavexx from comment #0) > Since I generally override the default flags in makefiles by appending > exceptions where needed, I expect the regular behavior where the last flags > overrides previous ones and thus found the current behavior unexpected. Why would either you or the makefile add something like -march=opteron on a haswell host? Surely the makefile should only add option that make sense, and you should only override them with options that make sense.
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #2 from wavexx at thregr dot org --- On 25/01/16 18:38, redi at gcc dot gnu.org wrote: > Why would either you or the makefile add something like -march=opteron on a > haswell host? > > Surely the makefile should only add option that make sense, and you should > only > override them with options that make sense. I generally use -march=native for most of my in-house projects. However, on very few binaries part of a larger project I actually target some older ISAs so I simply append -march=[x] as an exception with the usual CFLAGS += I could also (as I'm currently doing) splice -march out of CFLAGS and/or override CFLAGS in the required rules, so it's not a huge deal (as outlined in the original discussion), but even if documented, I would find the current behavior unexpected. I would have expected -march=native to simply expand to -march=haswell so that I could override it normally as I do for almost everything else.
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- This is a symptom of a more general problem, which is that the general GCC options machinery does not know which options have a single value (-march=) and which options can have multiple values (-I). If it did, then the command-line could be filtered before processing to keep only the last setting. Some of it is done in prune_options but either it happens too late (after the driver has already messed up the command-line) or it only applies to negated options.
