Build fails with -march=native on Intel Skylake

[ilovezfs]

Building with -march=native fails on Intel Skylake (both v4.1.0 and HEAD)

bash-3.2$ sysctl -n machdep.cpu.brand_string hw.model hw.cpufamily
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
iMac17,1
939270559

939270559 -> 0x37fc219f -> Skylake

Full log:
https://gist.github.com/ilovezfs/867f9df96dc5b054cc99

Excerpt of the failure:

/usr/local/Library/ENV/4.3/clang   -I/tmp/hyperscan20160308-37150-9e11vj/build -I/tmp/hyperscan20160308-37150-9e11vj -I/tmp/hyperscan20160308-37150-9e11vj/src -isystem /tmp/hyperscan20160308-37150-9e11vj/include -isystem /usr/local/include -I/tmp/hyperscan20160308-37150-9e11vj/build/src/fdr  -O3 -std=c99 -Wall -Wextra -Wshadow -Wcast-qual -Werror -march=native -mtune=native -fvisibility=hidden -Wvla -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-self-assign -Wno-parentheses-equality -DNDEBUG   -o CMakeFiles/hs_exec.dir/src/fdr/teddy.c.o   -c /tmp/hyperscan20160308-37150-9e11vj/src/fdr/teddy.c
In file included from /tmp/hyperscan20160308-37150-9e11vj/src/fdr/teddy.c:31:
/tmp/hyperscan20160308-37150-9e11vj/src/util/simd_utils_ssse3.h:37:2: error: SSSE3 instructions must be enabled
#error SSSE3 instructions must be enabled
 ^
/tmp/hyperscan20160308-37150-9e11vj/src/util/simd_utils_ssse3.h:73:12: error: assigning to 'm128' (aka '__m128i') from incompatible type 'int'
    result = _mm_shuffle_epi8(a, b);
           ^ ~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/hyperscan20160308-37150-9e11vj/src/fdr/teddy.c:244:
/tmp/hyperscan20160308-37150-9e11vj/build/src/fdr/teddy_autogen.c:14490:25: error: assigning to 'm128' (aka '__m128i') from incompatible type 'int'
        res_shifted_0_1 = palignr(res_0_1, res_old_1, 16-1);

[mdb256]

Thanks for reporting this. This appears to be an issue with Clang/Xcode.

I don't have a 6th Gen Core (aka Skylake) machine running OS X, but I can replicate this using clang-3.6 on Linux on a Core i5-6600K.

Running clang -### -c -march=native -E - on Linux, the output contains the flags -target-cpu x86-64 so clang is failing to pick up the processor model. Further clang -march=native -dM -E - < /dev/null | grep SSE shows that the defines for anything over SSE2 aren't available (SSE2 is part of the x86-64 standard).

Clang-3.7 currently reports the target cpu as "broadwell", which is more accurate. There is no guarantee for when these processor detection improvements will make it into Xcode builds, though.

We will improve our CMake feature testing so we can pick this up earlier in the build process - relying on -march=native and not checking is obviously fragile.

A workaround right now is to add -march=core-avx2 to CFLAGS.

I'm no homebrew expert - far from it, in fact - but I was able to test this by running brew edit hyperscan and adding "-DCMAKE_C_FLAGS='-march=core-avx2'", "-DCMAKE_CXX_FLAGS='-march=core-avx2'" after *std_cmake_flags on line 21.

[ilovezfs]

Unfortunately, that will still fail:

refurbishing removed:
-march=core-avx2
-O3
-Wall
-Wextra
-Wshadow
-Wcast-qual
-Werror
-Wvla
-Wpointer-arith
-Wstrict-prototypes
-Wmissing-prototypes

refurbishing added:
-pipe
-w
-Os
-march=native
-isystem/usr/local/include
-isystem/usr/include/libxml2
-isystem/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers

That, of course, is not your fault, but fixing it will require more intervention than that. It would be good if the source itself could be tweaked in some way not to fail with -march=native because that will be used unless a brew-very-non-standard system "xcrun", "make", "install" is used instead of a brew-standard system "make", "install".

[ilovezfs]

@mdb256 OK, good news!
Using
Command Line Tools OS X 10.11 for Xcode 7.3 beta 5
instead of
Command Line Tools OS X 10.11 for Xcode 7.2
gives us

< CLT: 7.2.0.0.1.1447826929
< Clang: 7.0 build 700
---
> CLT: 7.3.0.0.1.1456551150
> Clang: 7.3 build 703

and the problem is fixed.

Xcode 7.3 will probably be released simultaneously with OS X 10.11.4 which is currently at
10.11.4 Beta 6 (15E61b) (March 7, 2016; 1 day ago)

So the final release should be within days, not weeks.