| Summary: | libitm/config/x86/cacheline.h: '__m64' does not name a type | ||
|---|---|---|---|
| Product: | gcc | Reporter: | ncahill_alt |
| Component: | libitm | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gerald, jakub, rth, toolchain, torvald |
| Priority: | P3 | ||
| Version: | 4.7.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
What is the target which you are using? Sorry, i686-pc-linux-gnu, I think that is the target.
This is the configure command:
../gcc-4.7.0/configure \
--enable-bootstrap \
--disable-libada \
--disable-ld \
--disable-gold \
--enable-lto \
--enable-libssp \
\
--prefix=/usr \
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0 \
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include \
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0 \
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/man \
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/info \
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include/g++-v4 \
--host=i686-pc-linux-gnu \
--build=i686-pc-linux-gnu \
--disable-altivec \
--disable-fixed-point \
--without-ppl \
--without-cloog \
--enable-nls \
--without-included-gettext \
--with-system-zlib \
--disable-werror \
--enable-secureplt \
--disable-multilib \
--enable-libmudflap \
--disable-libgomp \
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.0/python \
--enable-checking=release \
--disable-libgcj \
--enable-languages=c,c++,fortran,lto \
--enable-shared \
--enable-threads=posix \
--enable-__cxa_atexit \
--enable-clocale=gnu \
--with-bugurl=http://bugs.gentoo.org/
Thank you.
> --enable-bootstrap \
Can you try without that?
(In reply to comment #3) > > --enable-bootstrap \ > > Can you try without that? I get the same error and the same workaround allows the build to complete. Looks like a bug in libitm/config/x86/target.h: // We'll be using some of the cpu builtins, and their associated types. #ifndef __cplusplus /* ??? It's broken for C++. */ #include <x86intrin.h> #else # ifdef __SSE2__ # include <emmintrin.h> # elif defined(__SSE__) # include <xmmintrin.h> # endif # ifdef __AVX__ # include <immintrin.h> # endif #endif No idea what "brokeness" the above talks about, it works just fine for me in C++, so IMHO it just should always include x86intrin.h, but certainly if __MMX__ is defined, but no __SSE__, the above won't include in C++ any header which would define __m64. Same here, building it from the FreeBSD port.
../../gcc-4.7-20120225/configure --disable-nls --enable-languages=c,c++,objc,fortran --libdir=/usr/local/lib/gcc47 --libexecdir=/usr/local/libexec/gcc47 --program-suffix=47 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc47/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion=FreeBSD Ports Collection --with-system-zlib --disable-libgcj --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc47 --build=i386-portbld-freebsd9.0
bails at:
libtool: compile: /var/tmp/export/ports/lang/gcc47/work/build/./gcc/g++ -B/var/
tmp/export/ports/lang/gcc47/work/build/./gcc/ -nostdinc++ -nostdinc++ -I/var/tmp
/export/ports/lang/gcc47/work/build/i386-portbld-freebsd9.0/libstdc++-v3/include
/i386-portbld-freebsd9.0 -I/var/tmp/export/ports/lang/gcc47/work/build/i386-port
bld-freebsd9.0/libstdc++-v3/include -I/var/tmp/export/ports/lang/gcc47/work/gcc-
4.7-20120225/libstdc++-v3/libsupc++ -I/var/tmp/export/ports/lang/gcc47/work/gcc-
4.7-20120225/libstdc++-v3/include/backward -I/var/tmp/export/ports/lang/gcc47/wo
rk/gcc-4.7-20120225/libstdc++-v3/testsuite/util -L/var/tmp/export/ports/lang/gcc47/work/build/i386-portbld-freebsd9.0/libstdc++-v3/src -L/var/tmp/export/ports/lang/gcc47/work/build/i386-portbld-freebsd9.0/libstdc++-v3/src/.libs -B/usr/local/i386-portbld-freebsd9.0/bin/ -B/usr/local/i386-portbld-freebsd9.0/lib/ -isystem /usr/local/i386-portbld-freebsd9.0/include -isystem /usr/local/i386-portbld-freebsd9.0/sys-include -DHAVE_CONFIG_H -I. -I../.././../gcc-4.7-20120225/libitm -I../.././../gcc-4.7-20120225/libitm/config/x86 -I../.././../gcc-4.7-20120225/libitm/config/posix -I../.././../gcc-4.7-20120225/libitm/config/generic -I../.././../gcc-4.7-20120225/libitm -march=i486 -mtune=i386 -fomit-frame-pointer -Wall -pthread -Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -Os -O2 -pipe -march=geode -mtune=geode -I/usr/local/include -fno-strict-aliasing -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c ../.././../gcc-4.7-20120225/libitm/aatree.cc -fPIC -DPIC -o .libs/aatree.o
In file included from ../.././../gcc-4.7-20120225/libitm/libitm_i.h:85:0,
from ../.././../gcc-4.7-20120225/libitm/aatree.cc:28:
../.././../gcc-4.7-20120225/libitm/config/x86/cacheline.h:55:3: error: '__m64' does not name a type
(In reply to Jakub Jelinek from comment #5) > No idea what "brokeness" the above talks about, it works just fine for me in > C++, so IMHO it just should always include x86intrin.h, but certainly if > __MMX__ is defined, but no __SSE__, the above won't include in C++ any > header which would define __m64. For 4.8 it just directly includes x86intrin.h. http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00467.html [1] However after patching 4.7.3 [2] we're seeing a different error on some systems. ---8<--- In file included from /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./gcc/include/x86intrin.h:27:0, from /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/libitm/config/x86/target.h:72, from /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/libitm/libitm_i.h:82, from /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/libitm/aatree.cc:28: /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./gcc/include/ia32intrin.h: In function ‘int __bsrd(int)’: /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./gcc/include/ia32intrin.h:41:35: error: ‘__builtin_ia32_bsrsi’ was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./gcc/include/ia32intrin.h: In function ‘long long unsigned int __rdpmc(int)’: /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./gcc/include/ia32intrin.h:89:35: error: ‘__builtin_ia32_rdpmc’ was not declared in this scope /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./gcc/include/ia32intrin.h: In function ‘long long unsigned int __rdtsc()’: /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/build/./gcc/include/ia32intrin.h:97:32: error: ‘__builtin_ia32_rdtsc’ was not declared in this scope --->8--- Both the reporters have AMD K8 processors. They only hit the bug when using -march=native; -march=k8 is successful. $ echo "" | gcc -march=native -v -E - 2>&1 | grep cc1 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - -march=k8 -mno-cx16 -mno-sahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8 So it seems there's still a piece missing. [1] http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193369 [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/gcc/4.7.3/gentoo/49_all_x86_pr52695_libitm-m64.patch?revision=1.1&view=markup Can this bug be closed? It sounds as if this has been fixed in 4.8 already; given that TM is experimental, backporting the fix is probably not worth it. Agreed. |
While building gcc 4.7.0, libitm fails with this error: In file included from ../../../gcc-4.7.0/libitm/libitm_i.h:85:0, from ../../../gcc-4.7.0/libitm/aatree.cc:28: ../../../gcc-4.7.0/libitm/config/x86/cacheline.h:55:3: error: '__m64' does not name a type A possible fix is to add #include <x86intrin.h> to cacheline.h, which seems to be the desired intent. This was built with gcc 4.6.2, from the gcc-4.7.0.tar.bz2 as released on ftp.gnu.org. The error occured right at the end, after the bootstrap process was successful. Thank you. Neil.