Bug 407281

Reversion is a wrong thing to do, there were dozens of changes.
Much better if somebody who can reproduce this does a binary search between
objects compiled with older and newer gcc and tracks this down to at least
one single .o file, then attaches here preprocessed source for that file and the
exact options passed to gcc to compile it.

I'm working on pinpointing what it breaks right now. To understand how, I'd need
the old gcc. Any binary RPM still stowed away somewhere?

gcc-4.1.2-33 in F8 GA is the predecessor of -34.

I have the same issue, and have narrowed the boot part to the kernel/hrtimer.o
object file.  If I replace it with one compiled with gcc-4.1.2-33, the system
boots normally, but once in X things are VERY sluggish, so my guess is that
other files are affected, maybe in the scheduler.

If it helps I can provide the bad and good hrtimer.o object files.

Created attachment 274801 [details]
pre-processed hrtimer.c

Attached pre-processed hrtimer.i file

From looking at the differences between the 4.1.2-33 and 4.1.2-34 versions of
the object file, it looks like the differences are mainly in the hrtimer_forward
function.

gcc command line is as follows:

  gcc -m32 -Wp,-MD,kernel/.hrtimer.o.d  -nostdinc -isystem
/usr/lib/gcc/i386-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude  -include
include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-save-temps -Os -pipe -msoft-float -mregparm=3 -freg-struct-return
-mpreferred-stack-boundary=2  -march=k8 -mtune=generic -ffreestanding
-maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
-Iinclude/asm-x86/mach-generic -Iinclude/asm-x86/mach-default
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g  -fno-stack-protector
-Wdeclaration-after-statement -Wno-pointer-sign     -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(hrtimer)"  -D"KBUILD_MODNAME=KBUILD_STR(hrtimer)"
-c -o kernel/.tmp_hrtimer.o kernel/hrtimer.c

For me the place it gets stuck is in tick_setup_sched_timer() in
kernel/time/tick-sched.c. It loops forever trying to calibrate the timer tick.

The problem seems to be rather generic in that gcc somehow messes with the
kernel's ability to proper calibrate time sources. Unfortunately I haven't kept
up with all the new timing stuff so I don't know what base value is being set up
incorrectly.

If it is really hrtimer_forward that is miscompiled (or buggy), then most
probably the relevant change is either http://gcc.gnu.org/PR33723 or
http://gcc.gnu.org/PR34146 since the function uses compound literals heavily.
That said, so far I don't see anything obviously wrong in the generated code, so
I'd appreciate any help in finding which exact function is problematic.
If you leave out -g, then there doesn't seem to be any difference between .L*
assignment, so it is easy to do a binary search in between functions.
Just compile with -S instead of -g -c (all other options kept unchanged) with
both compilers into hrtimer.s{33,34} and then always copy some functions from
hrtimer.s33 and the rest of functions from hrtimer.s34 into new hrtimer.s,
assemble it and test.  Thanks.

I can confirm that replacing just the hrtimer_forward function assembler code
with the one produced by 4.1.2-34 makes a bootable kernel non-bootable.

I'll attach the 4.1.2-33 and 4.1.2-34 version of that function's assembler code.

Created attachment 274881 [details]
Extracted assembly code for hrtimer_forward, gcc and cpp 4.1.2-33

Created attachment 274891 [details]
Extracted assembly code for hrtimer_forward, gcc and cpp 4.1.2-34

typedef union { long long int s; } U;
typedef struct { U u; } S;

void foo (S *s, long long int x, unsigned long int y)
{
  s->u = ({ (U) { .s = s->u.s + x * y }; });
}

is minimal testcase, gcc 4.3 doesn't exhibit this bug, so either it is a bug in
the backport, or some latent bug.  Will debug either tomorrow or on Monday.

Please retry with gcc-4.1.2-35, I've backported there two bugfixes from the
trunk that should cure this.

-35 works nicely. I'm now running 2.6.24-rc3 built with the updated gcc.

Good work :)

*** Bug 408101 has been marked as a duplicate of this bug. ***

*** Bug 406831 has been marked as a duplicate of this bug. ***