sorry if this goes into the wrong forum, I was unsure which one to choose, but this seemed the best choice to me.

Problem and workaround in short: current GCC in Gentoo seems to have a problem with CFLAGS "-march=native -O2 -pipe" on Intel Haswell CPU. Workaround: use "-march=core-avx-i -O2 -pipe"

Now, the long version:

Yesterday I got my new Intel i5-4670 CPU (after 5 years i finally decided to upgrade my home desktop a bit). After assembling the new hardware I tried a brand new stage3 install of gentoo and ran into a weird problem:

While installing Grub2, I got compile phase errors within the package dev-scheme/guile.
The error messages causing the failure are

First I blamed guile, but after I found out that I get similar errors while compiling some (not all!) other packages, like gcc, I tried different things until I tried setting the march-flag manually. After that, everything worked fine. If I set march back to native, the error returns.

So, since I use the same configs on different systems (Sandy & Ivy Bridge), I really believe GCC is selecting or handling something wrong with Intels newest CPU models (at least with my one).

Yesterday I got my new Intel i5-4670 CPU (after 5 years i finally decided to upgrade my home desktop a bit). After assembling the new hardware I tried a brand new stage3 install of gentoo and ran into a weird problem

Same here, still happens with current stage3... update GCC and don't forget to actually switch to it with gcc-config. With the current ~amd64 gcc everything seems to work fine. (no need for -9999 or unmasking anything or what ever)

If you want to use amd64 instead of ~amd64, well, it seems you have to wait a bit still and/or determine a working equivalent for march=native for now. Not sure which of the quadzillion options is the culprit really.

Support for Intel AVX2 intrinsics, built-in functions and code generation is available via -mavx2.
Support for Intel BMI2 intrinsics, built-in functions and code generation is available via -mbmi2.
Implementation and automatic generation of __builtin_clz* using the lzcnt instruction is available via -mlzcnt.
Support for Intel FMA3 intrinsics and code generation is available via -mfma.
A new -mfsgsbase command-line option is available that makes GCC generate new segment register read/write instructions through dedicated built-ins.
Support for the new Intel rdrnd instruction is available via -mrdrnd.
Two additional AVX vector conversion instructions are available via -mf16c.
Support for new Intel processor codename IvyBridge with RDRND, FSGSBASE and F16C is available through -march=core-avx-i.
Support for the new Intel processor codename Haswell with AVX2, FMA, BMI, BMI2, LZCNT is available through -march=core-avx2.
Support for new AMD family 15h processors (Piledriver core) is now available through -march=bdver2 and -mtune=bdver2 options.
Support for the x32 psABI is now available through the -mx32 option.
Windows mingw targets are using the -mms-bitfields option by default.
Windows x86 targets are using the __thiscall calling convention for C++ class-member functions.
Support for the configure option --with-threads=posix for Windows mingw targets.

-march=core-avx-i is for IvyBridge processors

I've many Haswell processors . No errors while compiling with -march=core-avx2

Allow -mpreferred-stack-boundary=3 for the x86-64 architecture with SSE extensions disabled. Since the x86-64 ABI requires 16 byte stack alignment, this is ABI incompatible and intended to be used in controlled environments where stack space is an important limitation. This option will lead to wrong code when functions compiled with 16 byte stack alignment (such as functions from a standard library) are called with misaligned stack. In this case, SSE instructions may lead to misaligned memory access traps. In addition, variable arguments will be handled incorrectly for 16 byte aligned objects (including x87 long double and __int128), leading to wrong results. You must build all modules with -mpreferred-stack-boundary=3, including any libraries. This includes the system libraries and startup modules.
Support for the new Intel processor codename Broadwell with RDSEED, ADCX, ADOX, PREFETCHW is available through -madx, -mprfchw, -mrdseed command-line options.
Support for the Intel RTM and HLE intrinsics, built-in functions and code generation is available via -mrtm and -mhle.
Support for the Intel FXSR, XSAVE and XSAVEOPT instruction sets. Intrinsics and built-in functions are available via -mfxsr, -mxsave and -mxsaveopt respectively.
New -maddress-mode=[short|long] options for x32. -maddress-mode=short overrides default 64-bit addresses to 32-bit by emitting the 0x67 address-size override prefix. This is the default address mode for x32.
New built-in functions to detect run-time CPU type and ISA:
A built-in function __builtin_cpu_is has been added to detect if the run-time CPU is of a particular type. It returns a positive integer on a match and zero otherwise. It accepts one string literal argument, the CPU name. For example, __builtin_cpu_is("westmere") returns a positive integer if the run-time CPU is an Intel Core i7 Westmere processor. Please refer to the user manual for the list of valid CPU names recognized.
A built-in function __builtin_cpu_supports has been added to detect if the run-time CPU supports a particular ISA feature. It returns a positive integer on a match and zero otherwise. It accepts one string literal argument, the ISA feature. For example, __builtin_cpu_supports("ssse3") returns a positive integer if the run-time CPU supports SSSE3 instructions. Please refer to the user manual for the list of valid ISA names recognized.

Caveat: If these built-in functions are called before any static constructors are invoked, like during IFUNC initialization, then the CPU detection initialization must be explicitly run using this newly provided built-in function, __builtin_cpu_init. The initialization needs to be done only once. For example, this is how the invocation would look like inside an IFUNC initializer:

It is now possible to create multiple function versions each targeting a specific processor and/or ISA. Function versions have the same signature but different target attributes. For example, here is a program with function versions:

Please refer to this wiki for more information.
The x86 backend has been improved to allow option -fschedule-insns to work reliably. This option can be used to schedule instructions better and leads to improved performace in certain cases.
Windows MinGW-w64 targets (*-w64-mingw*) require at least r5437 from the Mingw-w64 trunk.
Support for new AMD family 15h processors (Steamroller core) is now available through the -march=bdver3 and -mtune=bdver3 options.
Support for new AMD family 16h processors (Jaguar core) is now available through the -march=btver2 and -mtune=btver2 options.

Last week I set up a new Haswell system, first thing I did after stage3 was upgrade to gcc-4.7.3-r1 with 'march=core2' and then switch to the new gcc and 'march=native', zero problems._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Last week I set up a new Haswell system, first thing I did after stage3 was upgrade to gcc-4.7.3-r1 with 'march=core2' and then switch to the new gcc and 'march=native', zero problems.

march=native for Haswell pass "corei7-avx" instruction that is supported

Code:

# gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'

if you want a full instructions set for Hasweel set -march=core-avx2 according with gcc relase notes as above
(there was a patch to fix -march=native for Haswell processors somewhere in the forum if I remember...)

Do you have gcc-4.7.3 successfully working with '-march=core-avx2' on Haswell? I rather build without some flags than a hardmasked gcc-4.8.1_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic