FS#19248 - GCC produces corrupted binaries (Core i7, -march=native, x86_64)
Attached to Project:
Arch Linux
Opened by Andrej Podzimek (andrej) - Monday, 26 April 2010, 04:18 GMT
Last edited by Allan McRae (Allan) - Saturday, 22 May 2010, 07:59 GMT
Opened by Andrej Podzimek (andrej) - Monday, 26 April 2010, 04:18 GMT
Last edited by Allan McRae (Allan) - Saturday, 22 May 2010, 07:59 GMT
|
Details
Description:
I have always compiled my kernel with KCFLAGS='-march=native -O2 -pipe". Last time I did it, my kernel crashed with a lot of "invalid opcode" trap events. This happened after the upgrade to GCC 4.5. Not only the kernel is affected. Other programs seem to have problems as well. named[16311] trap invalid opcode ip:7fed777519ff sp:7fffd44622d0 error:0 in libisc.so.60.1.4[7fed7772d000+52000] blkid[1266] trap invalid opcode ip:3417611b0e sp:7fff70fb96e0 error:0 in libblkid.so.1.1.0[3417600000+1c000] hald-probe-volu[5174] trap invalid opcode ip:3417611b0e sp:7fffb0699c50 error:0 in libblkid.so.1.1.0[3417600000+1c000] ld[8577] trap invalid opcode ip:426dd0 sp:7fff0a9754f8 error:0 in ld[400000+87000] Additional info: * package version(s) 4.5.0-1 Steps to reproduce: Take a Core i7 (820QM, for instance), build your kernel with KCFLAGS="-march=native -O2 -pipe" and boot... (Well, you won't boot.) This is obviously an upstream bug, either wrong CPU detection or something more intricate. Should I report it somewhere else? BTW, it would be nice to have a "gcc44" package until this gets fixed. Pieces of advice like "man, why don't you use -march=core2?" sound great, ;-) but I just think -march=native *should* work. |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 22 May 2010, 07:59 GMT
Reason for closing: Fixed
Additional comments about closing: gcc-4.5.0-2
Saturday, 22 May 2010, 07:59 GMT
Reason for closing: Fixed
Additional comments about closing: gcc-4.5.0-2
gcc -Q -march=native --help=target | grep march
output?
2) -march= atom
Atom??? Does that mean GCC thinks I have an Atom?
[andrej@octopus pkg]$ cat /proc/cpuinfo | grep 'model name'
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
"I'm however a little puzzled why it uses march=atom for core i7 (lynnfield family) (mtune=core2 should be clear) - strange :?"
Binaries compiled with '-march=core2 -msse4 -msahf -mcx16 -O2 -pipe' seem to work just fine.
With just -march=core2 (and no other options), sse2 and ssse3 seem to be disabled. That's weird... AFAIK, Core2 implements all that stuff.
Yes, it does: the MOVBE instruction, which is unique to Intel Atoms. But it appears to be disabled when you select 'gcc -Q -march=native --help=target' (as shown in the first attachment).