gcc7 -march=native fails on compile for corei7

[bdmckay]

%% /opt/local/bin/gcc-mp-7 -v

Using built-in specs.
COLLECT_GCC=gcc7
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin16/7.2.0/lto-wrapper
Target: x86_64-apple-darwin16
Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc7/gcc7/work/gcc-7.2.0/configure --prefix=/opt/local --build=x86_64-apple-darwin16 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc7 --includedir=/opt/local/include/gcc7 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-7 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-7 --with-gxx-include-dir=/opt/local/include/gcc7/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-tls --with-pkgversion='MacPorts gcc7 7.2.0_0'
Thread model: posix
gcc version 7.2.0 (MacPorts gcc7 7.2.0_0)

%% cat basic.c

#include <stdio.h>

int main()
{
     double t;
     long int q;

     scanf("%ld",&q);
     t = q;
     printf("t = %f\n",t);

     return 0;
}

%% /opt/local/bin/gcc-mp-7 -c -march=native basic.c

/var/folders/vc/6bfn_k1j1bgbls8f6xg0pn8h0000gq/T//ccIvauBW.s:21:no such instruction: `vcvtsi2sdq %rax, %xmm0,%xmm0'
/var/folders/vc/6bfn_k1j1bgbls8f6xg0pn8h0000gq/T//ccIvauBW.s:22:no such instruction: `vmovsd %xmm0, -8(%rbp)'
/var/folders/vc/6bfn_k1j1bgbls8f6xg0pn8h0000gq/T//ccIvauBW.s:24:no such instruction: `vmovd %rax, %xmm0'

Comments: The hardware is a MacBook Pro, 13in Late 2012, 2.9 GHz Intel Core i7 processor. The instruction vcvtsi2sdq is in the AVX2 set, which corei7 does not support, so it should not be authorized by "-march=native". The i/o statements in the test program are just to prevent the compiler from optimizing away the type conversion; otherwise they don't seem relevant. The error goes away if "-march=native" is replaced by "-march=corei7" or replaced by "-march=native -mno-avx". The same problems occurred for gcc 7.1.1. Apologies if this is not macports-specific; I don't have an easy way to tell. If there is a better place to report this, please let me know.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

This problem seems to have been reported ​upstream, on ​stackoverflow, on ​stackoverflow, and on ​stackoverflow.

Upstream has a ​suggestion with an ​explanation.

I do not know if this is something MacPorts can fix on our end, but there is at least a fairly easy workaround (-Wa,-q).

[bdmckay]

Thanks. Clang can indeed do the assembling, but gcc7 -Wa,-q seems to only look for it at /opt/local/bin/clang. Creating a symbolic link from /opt/local/bin/clang to the XCode-installed /usr/bin/clang or a macports-installed /opt/local/bin/clang-mp-5.0 makes -Wa,-q work. This is ok for my personal use, but useless for package distribution since I can't expect my users to install an extra compiler or create a link that needs root privilege. I note that the upstream bug report is quite old; might it be that there just isn't much interest in getting recent versions of gcc working properly on Macs?

[RJVB (René Bertin)]

See also #54773 which introduces a small patch that makes the clang assembler the default.

I do not know if this is something MacPorts can fix on our end

There used to be a time when gcc used .spec files also for its default configuration. Nowadays that's all hardcoded so we have to patch the code if we want to change the default.

[kencu (Ken)]

the port select mechanism should take care of the symlinks for you, although it may not be a proper solution.

There are times when I would like the current version of gas on mac (the clang assembler is broken on PPC, and the old as doesn't understand newer instruction sets.)

[colinhowell (Colin Douglas Howell)]

This same problem is also the cause of tickets #36389 and #51642.

Incidentally, bdmckay, I think "vcvtsi2sdq %rax, %xmm0,%xmm0" (which is AT&T assembler syntax; in Intel syntax it would be "vcvtsi2sd xmm0, xmm0, rax") is actually in AVX, not AVX2. So it's legal for GCC, when run with -march=native, to generate it for your processor, which, for your MacBook Pro model, is an "Ivy Bridge", a somewhat later "Core i7" variant. "Core i7" is an Intel brand name for an entire family of processors, not all of which are the same; while the earliest Core i7s did not support AVX, all later ones do. GCC performs a detailed feature check to see what features are available.

Anyway, the problem is not that GCC generates the instruction, but that the assembler doesn't know what to do with it.