gcc 4.5.0 -Os does not generate correct code

[bdubbs@…]

I'm moving this from #2628 because it is a gcc issue.

I went though an svn build of the latest gcc-4.5 (svn revision (revision 159398) and the kernel segfaults when optimizing for size:

KBUILD_CFLAGS += -Os

Without this flag, the kernel boots fine. The issue may be limited to x86_64.

With my configuration, the kernel is about 3.6M when optimized and about 4.1M without.

For a more detailed description of my experimentation, see ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129

In the meantime there are a couple of options we have for lfs-svn:

1. Revert gcc to the latest gcc-4.4.x
2. Put a warning in the book not to optimize for size. AFAIK, the only package that does that by default is the kernel.
3. Do nothing and wait for gcc to release a fix.

[ken@…]

The only things I've built with 4.5 are kernels, but looking at my full logs from the last system build (LFS-6.6) the following used -Os : grub-1.97.2, cups, firefox (I think the latter because BLFS has --enable-optimize).

If I was a betting man, I'd put (a little) money on it only being x86_64 *and* only likely to show up in the kernel. I know firefox would be easy to change if it too shows the problem (--enable-optimize=-O2). For cups-1.4.3 I'm less sure, but I think it can be overridden --with-optim=-O2.

If you can confirm that the grub built by 4.5 on x86_64 is good, I suggest putting a warning for x86_64 on the kernel. If it does bite people on cups or firefox, we can put notes in the BLFS wiki until BLFS moves beyond 6.5,

[Matthew Burgess]

Bruce, I realise you've already done loads of work in tracking this issue down, but I'm wondering if you could figure out which optimization is the culprit? ​http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Optimize-Options.html#Optimize-Options lists all of the optimization options and most of those show at which optimization level they get turned on by.

What I'm thinking is if you could change the Kernel Makefile to set '-Os -fno-<optimzation option>' instead of plain '-Os' to selectively turn off individual optimization options that are explicitly mentioned in the manual as being turned on by '-Os'. I realise that this is probably going to be a fair bit of work unless you hit really lucky, so understand if you don't want to expend that effort.

[bdubbs@…]

Replying to matthew@…:

What I'm thinking is if you could change the Kernel Makefile to set '-Os -fno-<optimzation option>' instead of plain '-Os' to selectively turn off individual optimization options that are explicitly mentioned in the manual as being turned on by '-Os'. I realise that this is probably going to be a fair bit of work unless you hit really lucky, so understand if you don't want to expend that effort.

What I have to do to test this in the kernel is to remove the offending .o file, change the Makefile and remake the kernel. That wouldn't be too bad, but each test requires rebooting. Because I don't have an emulator on the target system, a crash means that I have to power cycle.

I suppose I could do:

-Os -fno<option1> -fno<option2> ...

Which should work if I disable all the options. Then removing the no from the options one at a time should work each time until I get to the problem option. From my reading, I suspect either -finline-small-functions or -findirect-inlining

Even that technique concerns me because of the statement "-Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size."

I don't know what the "further" optimizations are.

[Matthew Burgess]

Just as a further datapoint, my kernel boots fine here, compiled for a plain-old x86. Bruce, feel free to revert to GCC-4.4.3/4.4.4 if you think that's the best way forward for now.

[Petersen Liman]

Same here also when I upgraded my SVN

[houhongxun]

I think this bug is hardware dependent.My kernel compiled by gcc-4.5 for x86_64,with or without size optimization,has no problems.

[bdubbs@…]

Replying to hohoxu_hao115:

I think this bug is hardware dependent.My kernel compiled by gcc-4.5 for x86_64,with or without size optimization,has no problems.

Thanks for the feedback. The obvious question is "Did it boot properly." The build normally completes, but the kernel panics upon boot.

Can you post the results of cat \proc\cpuinfo

It would also help if you could run the following from the kernel directory:

gcc -Wp,-MD,arch/x86/kernel/.tsc.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/include -I/sources/linux-2.6.33.4-gcc45/arch/x86/include -Iinclude -include include/generated/autoconf.h -DKERNEL -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m64 -march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -fno-stack-protector

-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(tsc)"

-D"KBUILD_MODNAME=KBUILD_STR(tsc)" -S -c -o arch/x86/kernel/tsc.S arch/x86/kernel/tsc.c

and post arch/x86/kernel/tsc.S as an attachment

If you can check your log of the build, where arch/x86/kernel/tsc.c is built, does it match the above build string?

[bdubbs@…]

That should be:

 gcc -Wp,-MD,arch/x86/kernel/.tsc.o.d -nostdinc -isystem \
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/include \ 
 -I/sources/linux-2.6.33.4-gcc45/arch/x86/include -Iinclude \
 -include \
 include/generated/autoconf.h -DKERNEL -Wall -Wundef \
 -Wstrict-prototypes \
 -Wno-trigraphs -fno-strict-aliasing -fno-common \
 -Werror-implicit-function-declaration -Wno-format-security \
 -fno-delete-null-pointer-checks -Os -m64 -march=core2 \
 -mno-red-zone -mcmodel=kernel -funit-at-a-time \
 -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 \
 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare \
 -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 \
 -mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector \
 -fno-omit-frame-pointer -fno-optimize-sibling-calls \
 -Wdeclaration-after-statement -Wno-pointer-sign \
 -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack \
 -fno-stack-protector \
 -D"KBUILD_STR(s)=#s" \
 -D"KBUILD_BASENAME=KBUILD_STR(tsc)" \
 -D"KBUILD_MODNAME=KBUILD_STR(tsc)" \
 -S -c -o arch/x86/kernel/tsc.S arch/x86/kernel/tsc.c 

[houhongxun]

Replying to bdubbs@…:

Replying to hohoxu_hao115:

I think this bug is hardware dependent.My kernel compiled by gcc-4.5 for x86_64,with or without size optimization,has no problems.

Thanks for the feedback. The obvious question is "Did it boot properly." The build normally completes, but the kernel panics upon boot.

Can you post the results of cat \proc\cpuinfo

It would also help if you could run the following from the kernel directory:

gcc -Wp,-MD,arch/x86/kernel/.tsc.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/include -I/sources/linux-2.6.33.4-gcc45/arch/x86/include -Iinclude -include include/generated/autoconf.h -DKERNEL -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m64 -march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -fno-stack-protector

-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(tsc)"

-D"KBUILD_MODNAME=KBUILD_STR(tsc)" -S -c -o arch/x86/kernel/tsc.S arch/x86/kernel/tsc.c

and post arch/x86/kernel/tsc.S as an attachment

If you can check your log of the build, where arch/x86/kernel/tsc.c is built, does it match the above build string?

Yes,it boots fine.

/proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4256.09
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4255.76
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 2
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4255.77
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i3 CPU       M 330  @ 2.13GHz
stepping        : 2
cpu MHz         : 933.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 2
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4255.77
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

and I checked the build command of tsc.o, I can't find any differences with yours except kernel source path.

PS:In my build log,it's -DKERNEL, not -DKERNEL,may be this difference is related to kernel version(I use 2.6.34)?

Sorry for my english.

[bdubbs@…]

We got a fix on gcc bugzilla. I still don't know if the bug was in the kernel or gcc, but the following change to the kernel works around the problem

sed -i -e "s/inline void rdtsc_barrier/__always_inline void rdtsc_barrier/ \
 arch/x86/include/asm/system.h

The fix was just submitted today. We'll have to check future releases to see when it makes it into the released version.

[bdubbs@…]

Fixed at revision 9300.