gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

On Mon, Nov 15, 2010 at 11:54:46AM +0100, Andi Kleen wrote:
> > And for this the starting point should be what has been requested,
> > i.e. preprocessed source + gcc options + gcc version and some hints what
> > actually misbehaves (with the , "+m" (*regs) change reverted)
> > in gcc bugzilla.  Only with that we can actually look at what has been
> > happening, see whether it is the tree optimizations or RTL and which one
> > makes a difference.
> > If I've missed a PR about this I apologize. 
> 
> I tried to file one, but I can't reproduce it currently
> (I don't have hardware, so have to rely on code reading and the 32bit
> code looks correct to me even without the additional +m)
> 
> The preprocessed source is at
> http://halobates.de/tmp/i8k.i
> 
> Options I used:
> 
>  -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium3 -mtune=generic -maccumulate-outgoing-args -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=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 -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack

Indeed, with this and 4.5.2 20101111 (prerelease) from SVN as well as
gcc-4.5.1-5.fc14:

...
        movl    %eax, -16(%ebp) # regs, %sfp
        movl    (%eax), %eax    # regs_2(D)->eax,
        movl    %eax, -20(%ebp) #, %sfp
        movl    -16(%ebp), %eax # %sfp,
#APP
# 149 "/home/lsrc/git/linux-work2/drivers/char/i8k.c" 1
...
#NO_APP
        testl   %eax, %eax      #
        movl    $-22, %edx      #, D.18378
        movl    %eax, -24(%ebp) #, %sfp
        je      .L7     #,
.L2:
        movl    -12(%ebp), %ebx #,
        movl    %edx, %eax      # D.18378,
        movl    -8(%ebp), %esi  #,
        movl    -4(%ebp), %edi  #,
        movl    %ebp, %esp      #,
        popl    %ebp    #
        ret
        .p2align 4,,7
        .p2align 3
.L7:
        movl    -16(%ebp), %eax # %sfp,
        movl    (%eax), %ecx    # regs_2(D)->eax, D.18371
        cmpw    $-1, %cx        #, D.18371
        je      .L2     #,
        cmpl    %ecx, -20(%ebp) # D.18371, %sfp
        cmovne  -24(%ebp), %edx # %sfp,, D.18378
        jmp     .L2     #
        .size   i8k_smm, .-i8k_smm

I don't see any problems on the assembly level.  i8k_smm is
not inlined in this case and checks all 3 conditions.

Guess we need somebody who actually reported the problem, state what
gcc was actually used and post preprocessed source, gcc options
from his case.

	Jakub