4.7.0 fails to bootstrap on x86_64 (tested on Solaris 10 and CentOS 5.5) if the CPU doesn't support AVX (Xeon E5420) but the assembler (GNU as 2.22) does. For campatibility reasons I'm using "-march=core2", and GCC 4.6.3 builds without any problem with the same build script. checking whether /opt/SP/build/gcc/gcc-4.7.0/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/opt/SP/build/gcc/gcc-4.7.0/host-x86_64-unknown-linux-gnu/gcc/ -B/opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/bin/ -B/opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/lib/ -isystem /opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/include -isystem /opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/sys-include -m32 and cc understand -c and -o together... ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: variable or field â_ITM_WM256â declared void ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: âptrâ was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: variable or field â_ITM_WaRM256â declared void ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: âptrâ was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: variable or field â_ITM_WaWM256â declared void ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: âptrâ was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:86:19: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:86:35: error: ISO C++ forbids declaration of âptrâ with no type [-fpermissive] gmake[4]: *** [x86_avx.lo] Error 1 gmake[4]: Leaving directory `/opt/SP/build/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/libitm' I'm not a programmer, but on a first look the declaration of _ITM_TYPE_M256 seems to be missing if __AVX__ is not set, but HAVE_AS_AVX: ./libitm/libitm.h # ifdef __AVX__ typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias)); ITM_BARRIERS(M256) ITM_LOG(M256) # endif ./libitm/config/x86/x86_avx.cc #ifndef HAVE_AS_AVX // If we don't have an AVX capable assembler, we didn't set -mavx on the // command-line either, which means that libitm.h defined neither this type // nor the functions in this file. Define the type and unconditionally // wrap the file in extern "C" to make up for the lack of pre-declaration. typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias)); #endif But simply adding the definition (if defined(__AVX__) || defined(HAVE_AS_AVX)) just leads to an "avx vector argument without avx enabled changes the abi" error. As said above, I'm not a programmer. Adding "-mno-avx" does not change anything. I would expect AVX to be completely disabled if CPU and target architecture do not support it?
I have this problem too. I'm using Gentoo x86_64, with GNU binutils 2.22 as well. My CPU does support AVX (Intel Sandy Bridge.) It is using the following flags: -g -march=native -mtune=generic -mno-avx -O2 -pipe It is a pain for me because Valgrind doesn't support AVX and compiling programs with my system/default gcc version ends up using the 4.7 libgcc_s.so at run time which will contain AVX code if I compile with AVX enabled.
Created attachment 27589 [details] This patch works for me (I have no clue whether it is the "proper" fix.) This patch works for me (I have no clue whether it is the "proper" fix.) Compiles, I can compile stuff with the resulting g++, compiled stuff runs...
I can confirm that the attached patch solves the AVX problem for me as well (means on Solaris and CentOS), wether it is a "proper" one or not... Thanks! (BTW, now the compilation on Solaris fails with In file included from ./kinds.h:75:0, from ../../.././libgfortran/libgfortran.h:232, from ../../.././libgfortran/fmain.c:4: ../../.././libgfortran/kinds-override.h:40:5: error: #error "Where has __float128 gone?" gmake[6]: *** [fmain.lo] Error 1 gmake[6]: Leaving directory `/opt/SP/build/gcc/gcc-4.7.0/i386-pc-solaris2.10/amd64/libgfortran' *sigh* But this seems to be a different story...)
( And the "different story" is bug 53731... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53731 )
Ping?
I think I got the same error. This is on Gentoo Linux (some parts of emerge --info below, maybe revelant). libtool: compile: /var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/g++ -B/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/ -nostdinc++ -nostdinc++ -I/var/tmp/portag e/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v 3/include -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libstdc++-v3/libsupc++ -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libstdc++-v3/include/backward -I/v ar/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libstdc++-v3/testsuite/util -L/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp /portage/sys-devel/gcc-4.7.1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linu x-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm -I/var/tmp/portage/sys-devel/gcc-4 .7.1/work/gcc-4.7.1/libitm/config/linux/x86 -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/linux -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/lib itm/config/x86 -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/posix -I/var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/generic -I/var/tmp /portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm -Wall -pthread -Werror -mavx -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -march=nocona -mno-sse3 -O2 -pipe -D_GNU_SOURCE -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc -fPIC -DPIC -o .libs/ x86_avx.o depbase=`echo printf/mul_1.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ./libtool --tag=CC --mode=compile /var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/ -B/usr/x86_64-p c-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/port age/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libquadmath -g -march=nocona -mno-sse3 -O2 -pipe -m32 -MT printf/mul_1.lo -MD -MP -MF $depbase.Tpo -c -o printf/mul_1.lo /var/tmp/p ortage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libquadmath/printf/mul_1.c &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.7.1/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x 86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.7.1/work /gcc-4.7.1/libquadmath -g -march=nocona -mno-sse3 -O2 -pipe -m32 -MT printf/mul_1.lo -MD -MP -MF printf/.deps/mul_1.Tpo -c /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/ libquadmath/printf/mul_1.c -fPIC -DPIC -o printf/.libs/mul_1.o /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' does not name a type /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' does not name a type /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' does not name a type /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' does not name a type /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: variable or field '_ITM_WM256' declared void /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: 'ptr' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: variable or field '_ITM_WaRM256' declared void /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: 'ptr' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: variable or field '_ITM_WaWM256' declared void /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: 'ptr' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:83:1: error: '_ITM_TYPE_M256' was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:86:19: error: '_ITM_TYPE_M256' does not name a type /var/tmp/portage/sys-devel/gcc-4.7.1/work/gcc-4.7.1/libitm/config/x86/x86_avx.cc:86:35: error: ISO C++ forbids declaration of 'ptr' with no type [-fpermissive] make[4]: *** [x86_avx.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... emerge --info: System uname: Linux-3.4.3-x86_64-Intel-R-_Core-TM-_i3_CPU_M_350_@_2.27GHz-with-gentoo-2.2 CFLAGS="-march=nocona -mno-sse3 -O2 -pipe"
Ping? Bug still exists in 4.7.2, just tested on Solaris 10 and Linux (CentOS 5.5)
That is a user error, just don't do that. As the user provided CFLAGS/CXXFLAGS override the default flags, you really shouldn't be using -mno-this and -mno-that when building gcc, because that will disable what is required to compile gcc successfully. If you want to build gcc to support some CPU that doesn't have AVX etc., just configure it for such a CPU.
Well, the trouble is nowadays that many CPUs are exactly "this, except without that". But anyways, the test is fragile. There is no reason something like -march=core2 -mno-sse3 should cause this to fail (I don't think it should even try to build it in the first place, but I'm sure there must be a reason). So if this code expects and requires -mavx to compile, append it after the user's CFLAGS rather than letting them blow their feet off.
(In reply to comment #8) In fact I [suppose I] do as you suggest: I use "-march=core2" to prevent it from using AVX. The problem is that this is inconsistently overruled by the capabilities reported by the assembler (HAVE_AS_AVX). IMHO these capabilities are not properly matched against the architecture/target flags, please have a close look at my original posting and the easy workaround. Besides that I agree with Ryan, this shouldn't break the build anyway.
I have the same problem with snapshot 4.9-20131222. Makefile:517: recipe for target 'x86_avx.lo' failed: libtool: compile: /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/./gcc/xg++ -B/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/./gcc/ -nostdinc++ -nostdinc++ -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libstdc++-v3/libsupc++ -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libstdc++-v3/include/backward -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libstdc++-v3/testsuite/util -L/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/linux/x86 -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/linux -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/x86 -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/posix -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/generic -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm -mrtm -Wall -pthread -Werror -mavx -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -O2 -ggdb -pipe -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow -D_GNU_SOURCE -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/x86/x86_avx.cc -fPIC -DPIC -o .libs/x86_avx.o I found qt-4.8.5 reporting existence of AVX and SSE 4.2 where I have Core2 only. So now I am rebuilding my Gentoo system with -O2 -ggdb -pipe -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow but GCC bootstrap ignores it and adds -mavx. Configuration of gcc source tree: /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0-alpha20131222 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131222/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131222/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.9.0_alpha20131222 --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog
(In reply to Jakub Jelinek from comment #8) > That is a user error, just don't do that. As the user provided > CFLAGS/CXXFLAGS override the default flags, you really shouldn't be using > -mno-this and -mno-that when building gcc, because that will disable what is > required to compile gcc successfully. If you want to build gcc to support > some CPU that doesn't have AVX etc., just configure it for such a CPU. I told it to GCC bootstrap (having C,XXFlags containing -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow) and it ignored it completely.
Binutils rebuilt with -mno-avx and co. not helps.
I couldn't tell what the problem is. I have no problem to configure GCC with /export/gnu/import/git/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --prefix=/usr/local --enable-gnu-indirect-function --with-arch=native --with-cpu=native --with-fpmath=sse on a non-AVX machine with AVX binutils. x86_avx.cc was compiled with /export/build/gnu/gcc-native/build-x86_64-linux/./gcc/xg++ -B/export/build/gnu/gcc-native/build-x86_64-linux/./gcc/ -nostdinc++ -nostdinc++ -I/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc/libstdc++-v3/testsuite/util -L/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc-native/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/export/gnu/import/git/gcc/libitm -I/export/gnu/import/git/gcc/libitm/config/linux/x86 -I/export/gnu/import/git/gcc/libitm/config/linux -I/export/gnu/import/git/gcc/libitm/config/x86 -I/export/gnu/import/git/gcc/libitm/config/posix -I/export/gnu/import/git/gcc/libitm/config/generic -I/export/gnu/import/git/gcc/libitm -march=i486 -mtune=i686 -fomit-frame-pointer -mrtm -Wall -pthread -Werror -mavx -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -D_GNU_SOURCE -m32 -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c /export/gnu/import/git/gcc/libitm/config/x86/x86_avx.cc -o x86_avx.o There is -mavx in CXXFLAGS. But it won't be used at run-time since my machine doesn't have AVX.
For me it looks like that GCC build process is taking from some internal definition that AVX should be present on Core2 and enables it for libitm. Patch attached in this bug report works for gcc-4.9-20131222 fine too. "Known to fail" can contain 4.8.2 (and 4.9.0 branch too if possible). Gcc knows that there is no AVX, both for 4.8.2 and 4.9.0 snapshot but both versions enable AVX for libitim for me: 4.9.0: gcc -march=native -Q --help=targetThe following options are target specific: -m128bit-long-double [disabled] -m32 [disabled] -m3dnow [disabled] -m3dnowa [disabled] -m64 [enabled] -m80387 [enabled] -m8bit-idiv [disabled] -m96bit-long-double [enabled] -mabi= sysv -mabm [disabled] -maccumulate-outgoing-args [disabled] -maddress-mode= short -madx [disabled] -maes [disabled] -malign-double [disabled] -malign-functions= 0 -malign-jumps= 0 -malign-loops= 0 -malign-stringops [enabled] -mandroid [disabled] -march= core2 -masm= att -mavx [disabled] -mavx2 [disabled] -mavx256-split-unaligned-load [disabled] -mavx256-split-unaligned-store [disabled] -mavx512cd [disabled] -mavx512er [disabled] -mavx512f [disabled] -mavx512pf [disabled] -mbionic [disabled] -mbmi [disabled] -mbmi2 [disabled] -mbranch-cost= 0 -mcld [disabled] -mcmodel= 32 -mcpu= -mcrc32 [disabled] -mcx16 [enabled] -mdispatch-scheduler [disabled] -mdump-tune-features [disabled] -mf16c [disabled] -mfancy-math-387 [enabled] -mfentry [enabled] -mfma [disabled] -mfma4 [disabled] -mforce-drap [disabled] -mfp-ret-in-387 [enabled] -mfpmath= 387 -mfsgsbase [disabled] -mfused-madd -mfxsr [enabled] -mglibc [enabled] -mhard-float [enabled] -mhle [disabled] -mieee-fp [enabled] -mincoming-stack-boundary= 0 -minline-all-stringops [disabled] -minline-stringops-dynamically [disabled] -mintel-syntax -mlarge-data-threshold= 0x10000 -mlong-double-64 [disabled] -mlong-double-80 [enabled] -mlwp [disabled] -mlzcnt [disabled] -mmemcpy-strategy= -mmemset-strategy= -mmmx [enabled] -mmovbe [disabled] -mms-bitfields [disabled] -mno-align-stringops [disabled] -mno-default [disabled] -mno-fancy-math-387 [disabled] -mno-push-args [disabled] -mno-red-zone [disabled] -mno-sse4 [disabled] -momit-leaf-frame-pointer [disabled] -mpc32 [disabled] -mpc64 [disabled] -mpc80 [disabled] -mpclmul [disabled] -mpopcnt [disabled] -mprefer-avx128 [disabled] -mpreferred-stack-boundary= 0 -mprfchw [disabled] -mpush-args [enabled] -mrdrnd [disabled] -mrdseed [disabled] -mrecip [disabled] -mrecip= -mred-zone [enabled] -mregparm= 0 -mrtd [disabled] -mrtm [disabled] -msahf [enabled] -msoft-float [disabled] -msse [enabled] -msse2 [enabled] -msse2avx [disabled] -msse3 [enabled] -msse4 [disabled] -msse4.1 [enabled] -msse4.2 [disabled] -msse4a [disabled] -msse5 -msseregparm [disabled] -mssse3 [enabled] -mstack-arg-probe [disabled] -mstack-protector-guard= tls -mstackrealign [enabled] -mstringop-strategy= [default] -mtbm [disabled] -mtls-dialect= gnu -mtls-direct-seg-refs [enabled] -mtune-ctrl= -mtune= core2 -muclibc [disabled] -mveclibabi= [default] -mvect8-ret-in-mem [disabled] -mvzeroupper [disabled] -mx32 [disabled] -mxop [disabled] -mxsave [disabled] -mxsaveopt [disabled] Known assembler dialects (for use with the -masm-dialect= option): att intel Known ABIs (for use with the -mabi= option): ms sysv Known code models (for use with the -mcmodel= option): 32 kernel large medium small Valid arguments to -mfpmath=: 387 387+sse 387,sse both sse sse+387 sse,387 Known vectorization library ABIs (for use with the -mveclibabi= option): acml svml Known address mode (for use with the -maddress-mode= option): long short Known stack protector guard (for use with the -mstack-protector-guard= option): global tls Valid arguments to -mstringop-strategy=: byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop vector_loop Known TLS dialects (for use with the -mtls-dialect= option): gnu gnu2 4.8.2: /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc -march=native -Q --help=target The following options are target specific: -m128bit-long-double [disabled] -m32 [disabled] -m3dnow [disabled] -m3dnowa [disabled] -m64 [enabled] -m80387 [enabled] -m8bit-idiv [disabled] -m96bit-long-double [enabled] -mabi= sysv -mabm [disabled] -maccumulate-outgoing-args [disabled] -maddress-mode= short -madx [disabled] -maes [disabled] -malign-double [disabled] -malign-functions= 0 -malign-jumps= 0 -malign-loops= 0 -malign-stringops [enabled] -mandroid [disabled] -march= core2 -masm= att -mavx [disabled] -mavx2 [disabled] -mavx256-split-unaligned-load [disabled] -mavx256-split-unaligned-store [disabled] -mbionic [disabled] -mbmi [disabled] -mbmi2 [disabled] -mbranch-cost= 0 -mcld [disabled] -mcmodel= 32 -mcpu= -mcrc32 [disabled] -mcx16 [enabled] -mdispatch-scheduler [disabled] -mf16c [disabled] -mfancy-math-387 [enabled] -mfentry [enabled] -mfma [disabled] -mfma4 [disabled] -mforce-drap [disabled] -mfp-ret-in-387 [enabled] -mfpmath= 387 -mfsgsbase [disabled] -mfused-madd -mfxsr [enabled] -mglibc [enabled] -mhard-float [enabled] -mhle [disabled] -mieee-fp [enabled] -mincoming-stack-boundary= 0 -minline-all-stringops [disabled] -minline-stringops-dynamically [disabled] -mintel-syntax -mlarge-data-threshold= 0x10000 -mlong-double-64 [disabled] -mlong-double-80 [enabled] -mlwp [disabled] -mlzcnt [disabled] -mmmx [disabled] -mmovbe [disabled] -mms-bitfields [disabled] -mno-align-stringops [disabled] -mno-fancy-math-387 [disabled] -mno-push-args [disabled] -mno-red-zone [disabled] -mno-sse4 [disabled] -momit-leaf-frame-pointer [disabled] -mpc32 [disabled] -mpc64 [disabled] -mpc80 [disabled] -mpclmul [disabled] -mpopcnt [disabled] -mprefer-avx128 [disabled] -mpreferred-stack-boundary= 0 -mprfchw [disabled] -mpush-args [enabled] -mrdrnd [disabled] -mrdseed [disabled] -mrecip [disabled] -mrecip= -mred-zone [enabled] -mregparm= 0 -mrtd [disabled] -mrtm [disabled] -msahf [enabled] -msoft-float [disabled] -msse [enabled] -msse2 [enabled] -msse2avx [disabled] -msse3 [enabled] -msse4 [disabled] -msse4.1 [enabled] -msse4.2 [disabled] -msse4a [disabled] -msse5 -msseregparm [disabled] -mssse3 [enabled] -mstack-arg-probe [disabled] -mstackrealign [enabled] -mstringop-strategy= [default] -mtbm [disabled] -mtls-dialect= gnu -mtls-direct-seg-refs [enabled] -mtune= core2 -muclibc [disabled] -mveclibabi= [default] -mvect8-ret-in-mem [disabled] -mvzeroupper [disabled] -mx32 [disabled] -mxop [disabled] -mxsave [disabled] -mxsaveopt [disabled] Known assembler dialects (for use with the -masm-dialect= option): att intel Known ABIs (for use with the -mabi= option): ms sysv Known code models (for use with the -mcmodel= option): 32 kernel large medium small Valid arguments to -mfpmath=: 387 387+sse 387,sse both sse sse+387 sse,387 Known vectorization library ABIs (for use with the -mveclibabi= option): acml svml Known address mode (for use with the -maddress-mode= option): long short Valid arguments to -mstringop-strategy=: byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop Known TLS dialects (for use with the -mtls-dialect= option): gnu gnu2
(In reply to David Kredba from comment #15) > For me it looks like that GCC build process is taking from some internal > definition that AVX should be present on Core2 and enables it for libitm. > Patch attached in this bug report works for gcc-4.9-20131222 fine too. > > "Known to fail" can contain 4.8.2 (and 4.9.0 branch too if possible). > > Gcc knows that there is no AVX, both for 4.8.2 and 4.9.0 snapshot but both What is exactly the problem? How can I reproduce it? > versions enable AVX for libitim for me: > That is intentional. AVX is always compiled in if your binutils supports it. When you copy the same GCC run-time library binaries you built on non-AVX machine, including libitm, to an AVX machine, the AVX functions are checked and used at the run-time if OS/HW support AVX.
I can't bootstrap 4.9.0 snapshots without patch attached. My machine is Core2 Quad where are not any avx instructions available. All is compiled from sources (Gentoo) but libitm x86_avx.lo crashes bootstrap. -march=native is by gcc translated to core2 what is correct. I saw qt 4.8.5 qmake reporting AVX available too, which is wrong. After I used -mno-avx it stopped doing it. Gcc knows there is no avx. Binutils reports AVX instruction set support anyway as supported - it can work with it in code. The fact that code produced will not run on host system is not burning them looks like. I recompiled them with -mno-avx to be sure that tests for AVX will fail but GNU as reports them an thus libitm still crashes bootstrap. In my opinion if gcc cannot trust GNU AS it should tell itsef to libitm configure what instructions sets are really available. I think that reproducing needs machine where CPU does not know what AVX is. Thank you.
(In reply to David Kredba from comment #17) > > I think that reproducing needs machine where CPU does not know what AVX is. I have non-AVX machines and I have no problems with bootstrapping GCC 4.9.0 on them. So far no one has described how to reproduce the issue.
When -mno-avx is added to CXXFLAGS, x86_avx.cc failed to compile: /bin/sh ./libtool --tag=CXX --mode=compile /export/build/gnu/gcc-misc/build-x86_64-linux/./gcc/xg++ -B/export/build/gnu/gcc-misc/build-x86_64-linux/./gcc/ -nostdinc++ -nostdinc++ -I/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc/libstdc++-v3/testsuite/util -L/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc-misc/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/gcc-4.9.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.9.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.9.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.9.0/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/export/gnu/import/git/gcc/libitm -I/export/gnu/import/git/gcc/libitm/config/linux/x86 -I/export/gnu/import/git/gcc/libitm/config/linux -I/export/gnu/import/git/gcc/libitm/config/x86 -I/export/gnu/import/git/gcc/libitm/config/posix -I/export/gnu/import/git/gcc/libitm/config/generic -I/export/gnu/import/git/gcc/libitm -march=i486 -mtune=i686 -fomit-frame-pointer -mrtm -Wall -Werror -Wc,-pthread -mavx -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -mno-avx -D_GNU_SOURCE -m32 -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c -o x86_avx.lo /export/gnu/import/git/gcc/libitm/config/x86/x86_avx.cc
(In reply to David Kredba from comment #17) > I can't bootstrap 4.9.0 snapshots without patch attached. My machine is > Core2 Quad where are not any avx instructions available. All is compiled > from sources (Gentoo) but libitm x86_avx.lo crashes bootstrap. -march=native > is by gcc translated to core2 what is correct. > The problem is -mno-avx is added by hand. GCC won't use generate AVX instructions with -march=native only if your machine supports AVX. x86_avx.cc is compiled with -mavx on purpose. libitm checks if AVX is supported at run-time and uses x86_avx if AVX is supported. -mno-avx shouldn't added by hand to bootstrap GCC. I think we should close this bug as WONTFIX.
Well in practice we've had to have users build GCC with -mno-avx on no less than three occasions since 4.4 due to compiler bugs on certain chips (usually newer chips + old releases), so it'd be nice to have it just work. If x86_avx.cc must be compiled with -mavx then can it be appended after user CFLAGS? That should make everyone happy.
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01877.html
Author: hjl Date: Mon Jan 13 19:36:17 2014 New Revision: 206587 URL: http://gcc.gnu.org/viewcvs?rev=206587&root=gcc&view=rev Log: Make sure that -msse/-mavx are appended at the end PR libitm/53113 * Makefile.am (x86_sse.lo): Append -msse to CXXFLAGS. (x86_avx.lo): Append -mavx to CXXFLAGS. * Makefile.in: Regenerate. Modified: trunk/libitm/ChangeLog trunk/libitm/Makefile.am trunk/libitm/Makefile.in
Unsetting target milestone of open non-regression bug from version of branch being closed.
(In reply to hjl@gcc.gnu.org from comment #24) > Author: hjl > Date: Mon Jan 13 19:36:17 2014 > New Revision: 206587 > > URL: http://gcc.gnu.org/viewcvs?rev=206587&root=gcc&view=rev > Log: > Make sure that -msse/-mavx are appended at the end > > PR libitm/53113 > * Makefile.am (x86_sse.lo): Append -msse to CXXFLAGS. > (x86_avx.lo): Append -mavx to CXXFLAGS. > * Makefile.in: Regenerate. > > Modified: > trunk/libitm/ChangeLog > trunk/libitm/Makefile.am > trunk/libitm/Makefile.in H.J., can this bug be closed?
Fixed for 4.9.0.