Compile errors on Intel Haswell CPU

[EvilGeniusHST]

Hello everyone,

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

Code: Select all

{standard input}:7885: Error: no such instruction: `vfmadd312sd .LC2(%rip),%xmm0,%xmm1'
{standard input}:7936: Error: no such instruction: `vfmadd312sd .LC2(%rip),%xmm4,%xmm1'
{standard input}:7957: Error: no such instruction: `vfmadd312sd .LC2(%rip),%xmm0,%xmm4'

which subsequently caused emaike to fail.

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).

Here is the output of

Code: Select all

diff -uNr <(echo|gcc -dM -E - -march=core-avx-i) <(echo|gcc -dM -E - -march=native)

(slightly edited for better readibility)

Code: Select all

+#define __ABM__ 1
-#define __F16C__ 1
+#define __FP_FAST_FMAF 1
-#define __tune_corei7__ 1
+#define __FMA__ 1
-#define __RDRND__ 1
+#define __FP_FAST_FMA 1
-#define __FSGSBASE__ 1
+#define __BMI__ 1

I've not included more output since the installation of the new system is still in progress. If you need more, just ask...

[roarinelk]

emerge binutils-9999

[darklegion]

You could try gcc-4.8.1 which was just released into the main tree. Sometimes "-march=native" has trouble with new CPUs in older gcc versions (as you'd expect).

[frostschutz]

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.

[sabayonino]

Hashwell Processors has -march=core-avx2 (-march=native still not support )

for >=gcc-4.7.2

http://gcc.gnu.org/gcc-4.7/changes.html

IA-32/x86-64

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


gcc >=4.8.x
http://gcc.gnu.org/gcc-4.8/changes.html

IA-32/x86-64

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:

static void (*some_ifunc_resolver(void))(void)
{
__builtin_cpu_init();
if (__builtin_cpu_is("amdfam10h") ...
if (__builtin_cpu_supports("popcnt") ...
}


Function Multiversioning Support with G++:

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:

__attribute__ ((target ("default")))
int foo(void)
{
return 1;
}

__attribute__ ((target ("sse4.2")))
int foo(void)
{
return 2;
}

int main (void)
{
int (*p) = &foo;
assert ((*p)() == foo());
return 0;
}


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.

[asturm]

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.

[sabayonino]

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: Select all

# 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...)

This is the output for one my Haswell processors running gcc-4.8.1

Code: Select all

gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
-march=corei7-avx -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 -mtune=generic

as you can see "native" read -march as "corei7-avx"

[asturm]

Still, the avx2 flag is set in your output.

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

[sabayonino]

Still, the avx2 flag is set in your output.

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

compiled with 4.7.2 and 4.7.3 for a lot (now removed) ... core-avx2 no errors reporteedd for me.

Code: Select all

emerge --info
Portage 2.2.1 (default/linux/amd64/13.0/desktop/kde, gcc-4.8.1, glibc-2.15-r3, 3.11.0-gentoo x86_64)
=================================================================
System uname: Linux-3.11.0-gentoo-x86_64-Intel-R-_Core-TM-_i7-4770_CPU_@_3.40GHz-with-gentoo-2.2
KiB Mem:    16379324 total,   6986484 free
KiB Swap:    1048572 total,   1048480 free
Timestamp of tree: Sun, 06 Oct 2013 09:45:01 +0000
ld ld di GNU (GNU Binutils) 2.23.1
distcc 3.1 x86_64-pc-linux-gnu [disabled]
ccache version 3.1.9 [enabled]
app-shells/bash:          4.2_p45
dev-java/java-config:     2.1.12-r1
dev-lang/python:          2.6.8-r3, 2.7.5-r2, 3.1.5-r1, 3.3.2-r1
dev-util/ccache:          3.1.9
dev-util/cmake:           2.8.10.2-r2
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.11.6, 1.12.6, 1.13.4
sys-devel/binutils:       2.23.1
sys-devel/gcc:            4.6.3, 4.8.1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc:           2.15-r3
Repositories: gentoo proaudio
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=core-avx2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/config/kdm /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo"
CXXFLAGS="-O2 -march=core-avx2 -pipe"
DISTDIR="/usr/portage/distfiles/distfiles"
EMERGE_DEFAULT_OPTS="--quiet-build=n"
FCFLAGS="-O2 -pipe"

[...]

[edit] GCC Core-AVX2 "Haswell" CPU Optimization Tests
and
Gcc Options (Doc)

http://openbenchmarking.org/result/1308 ... CC49SNAP71
core-avx2 has
1/22 Red Flag (lame mp3 encoding)
12/22 Green Flag
9/22 Blue Flag

for all tests

[sabayonino]

with gcc-4.8.1-r1 (4.7.2-r1 - 4.7.3-r1) , -march=native recognised Haswell processors (and others)

Code: Select all

# gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
-march=core-avx2 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 -mtune=core-avx2

Haswell Flags

Code: Select all

 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm

[wlos]

Had exactly the same problem wih i5-4570 when compiling links.

I switched to gcc-4.7.3 from gcc.4.6.x and it worked.