hyperscan: leave -march=native to the build system

[ilovezfs]

The default is -march=native but explicitly setting it can cause build failure. In particular, --build-from-source fails on iMac with :skylake.

Here's are the gist-logs showing the failure case:
https://gist.github.com/5357e306bfcc0e702730

And here's how a successful build looks with this PR in place:
https://gist.github.com/ilovezfs/1d0f2aa32c7bfff0d971

Note that -march=native is indeed used as part of the default when HOMEBREW_OPTFLAGS is deleted.

[MikeMcQuaid]

Can you report this upstream? Feels weird that us setting us breaks things.

[ilovezfs]

@MikeMcQuaid Ah it was actually ENV tricking me. Calling "make" refurbishes the args, so it's stripping

stripped: 
-O3
-Wall
-Wextra
-Wshadow
-Wcast-qual
-Werror
-march=native
-mtune=native
-Wvla
-Wpointer-arith
-Wstrict-prototypes
-Wmissing-prototypes

So with the patch in the PR, I can still make it fail by running system "xcrun", "make", "install"

That makes more sense now! I will report it to upstream as a problem with -march=native itself and this particular hardware.

[ilovezfs]

@MikeMcQuaid FYI upstream was able to replicate the issue using clang-3.6 on Linux on a Core i5-6600K (intel/hyperscan#15 (comment)), but I have now closed the upstream issue: intel/hyperscan#15 (comment)

Using Xcode 7.3 (beta 5) fixes the problem, so this should take care of itself shortly.

Is there any way to specify in the formula that certain architectures (Skylake is affected, Ivy Bridge is not, and I'm not sure about Haswell and Broadwell) will require at least Clang 7.3 build 703 but will fail with Clang 7.0 build 700 and below? Or is it just not worth it to bother since eventually everyone will be on >= Xcode 7.3?

[MikeMcQuaid]

@ilovezfs I'm OK with merging a fix until upstream merge a patch or Xcode 7.3 has been released?