Summary: | sys-devel/gcc-4.5.3-r1 uses -mtune=generic instead of -mtune=core2 when using -march=native | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | bug, prometheanfire |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
cpuid.c
x86-64 not detected properly, config.log |
Description
Pacho Ramos
![]() Imho is because gcc-4.5 works better with -mtune=generic instead of specific It's only using generic for the laptop with i5 processor Created attachment 287455 [details]
cpuid.c
post the output from this:
gcc cpuid.c && ./a.out
This is causing qemu-kvm-0.15 to make gcc thing that it is a simple pentium-m vs native (core2 usually (this is a first gen i7)). Notice the colect_gcc_options Configured with: /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-esp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.5.3-r1 p1.0, pie-0.4.5' Thread model: posix gcc version 4.5.3 (Gentoo Hardened 4.5.3-r1 p1.0, pie-0.4.5) COLLECT_GCC_OPTIONS='-B/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/gcc/' '-c' '-g' '-O2' '-pipe' '-v' '-Q' '-fPIE' '-pie' cc1 -v -iprefix /root/../../../lib/gcc/x86_64-pc-linux-gnu/4.5.3/ conftest.c -D_FORTIFY_SOURCE=2 -march=pentium-m -mcx16 -msahf -mpopcnt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic -fno-strict-overflow -dumpbase conftest.c -auxbase conftest -g -O2 -version -fPIE -fstack-protector-all -o - | as -V -Qy --64 -o conftest.o - GCC versions before 4.6 don't have a proper cost model for Core and later processors. Tuning for generic produces better code in 4.5 so it's the default. (In reply to comment #5) > GCC versions before 4.6 don't have a proper cost model for Core and later > processors. Tuning for generic produces better code in 4.5 so it's the > default. This is causing my x86_64 vm to be detected as only being 32bit. I attached this file, look at line 99 /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/x86_64-pc-linux-gnu/libgcc/config.log Created attachment 287457 [details]
x86-64 not detected properly, config.log
/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/x86_64-pc-linux-gnu/libgcc/config.log
I have added bug 384149 since this is a march detection issue, not mtune. (In reply to comment #3) > Created attachment 287455 [details] > cpuid.c > > post the output from this: > gcc cpuid.c && ./a.out This one: $ gcc cpuid.c && ./a.out 0x1: 0x206a7 0x1100800 0x1fbae3bf 0xbfebfbff 0x80000000: 0x80000008 0 0 0 0x80000001: 0 0 0x1 0x28100800 0x80000002: 0x20202020 0x49202020 0x6c65746e 0x20295228 (In reply to comment #5) > GCC versions before 4.6 don't have a proper cost model for Core and later > processors. Tuning for generic produces better code in 4.5 so it's the > default. Are you sure then "core2" with gcc-4.4 was producing slower code than "generic" on gcc-4.5? Please note that I am getting this problem only on a i5 process, other core2 models looks to still be detected ok by gcc-4.5 Looks like this have changed in gcc-4.6: \_ /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/cc1 -quiet - -D_FORTIFY_SOURCE=2 -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=corei7-avx -quiet -dumpbase - -auxbase-strip /dev/null -o /tmp/ccgcWHIx.s (well, mine is i5 instead of i7, but I guess corei7-avx is also valid for it). I guess I will need to help on fixing gcc-4.6 tracker bugs to try to get it stabilized soon ;) Pacho, with gcc-4.6.3 I have the same problem, CPU E3-1230 V2 @ 3.30GHz. Gcc detect it as "corei7-avx". (In reply to comment #11) > Pacho, with gcc-4.6.3 I have the same problem, CPU E3-1230 V2 @ 3.30GHz. Gcc > detect it as "corei7-avx". I would open a different bug as it refers to a different CPU, and also report to upstream to verify it's not expected Not a bug. |