xfs
[Top] [All Lists]

RH 7.1 gcc 2.96 bug (was Re: TAKE - work around gcc bug during xfs_growf

To: Eric Sandeen <sandeen@xxxxxxx>
Subject: RH 7.1 gcc 2.96 bug (was Re: TAKE - work around gcc bug during xfs_growfs )
From: erich@xxxxxxxx
Date: Fri, 12 Oct 2001 00:59:04 -0700
Cc: linux-xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
In-reply-to: Your message of "Thu, 11 Oct 2001 11:59:20 CDT." <3BC5CFE8.84FDB6FC@sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Eric Sandeen <sandeen@xxxxxxx> wrote:

> > You may want to check it against the rawhide -99 version, since you know
> > exactly what to test for.  If you'd like I could try that tonight for
> > you.
> 
> Sure, if you'd like to test it that would be great.  I was going to
> install that compiler RPM, but it needs a new binutils which needs a
> new glibc which needs...  :)
> 
> Take a look at that URL for the diff I posted, and back it out.
> 
> To test for the error,
...[example creating an XFS filesystem about 1/2 the partition size,
    then growing it to the full partition size]...
> If you see any errors, it didn't work.  :)

Well, I wasn't able to reproduce with your test case at all.  I suspect
that maybe it's the fact that I only had a 2GB spare partition to try it
on.

On the positive (??!?) side, I looked at the disassembly and found
what the compiler is doing wrong in the case you worked around
(ok, so you probably already know this, but I'm putting this here
so that someone can fix the bug or convince RedHat to move to
away from 2.96, maybe to 3.x).

In the second one of the 5 cases of where you added a temporary rather
than a putting the macro in the function parameter sequence directly,
there are some operations done to what appear to be spill locations,
but the spill and reload are never performed...  so it seems these
locations were allocated for spill/reload, but then wires got crossed
somewhere.

In the "fixed" version, the exact same operations are performed
on the same stack locations, but the spill happens before and a reload
happens afterward, hence my suspicions.

Here is the assembly output difference (from the original and recently
"fixed" version of "linux/fs/xfs/xfs_fsops.c" in the linux-xfs CVS
tree):

   "original version":

        sall    %cl, %eax
        testb   $32, %cl
        cmovne  %eax, %edx
        cmovne  %edi, %eax

    [no spill?!?]

  -->   addl    $2, 16(%esp)
  -->   adcl    $0, 20(%esp)

    [no reload!?!]

        shldl   $9, %eax, %edx
        sall    $9, %eax
        pushl   %edx
        pushl   %eax


   "fixed version":

        sall    %cl, %eax
        testb   $32, %cl
        cmovne  %eax, %edx
        cmovne  %ebx, %eax
  S->   movl    %eax, 8(%esp)
  -->   addl    $2, 8(%esp)
  S->   movl    %edx, 12(%esp)
  -->   adcl    $0, 12(%esp)
        pushl   $8708
        movl    80(%esp), %ecx
        sall    $9, %ecx
        pushl   %ecx
  R->   movl    16(%esp), %eax
  R->   movl    20(%esp), %edx
        shldl   $9, %eax, %edx
        sall    $9, %eax
        pushl   %edx
        pushl   %eax


Note the ending code sequence to push the parameters on the stack
are the same, but in the first sequence, the operations are done
on memory locations that have no connection with the rest of the
code.  Ack.

It is very reproducable and happens in all the RedHat 7.1 gcc 2.96
series compiler versions I tried:  -81 (the one in the base release),
-85 (the one in RedHat's update set), -88, and -99 (the most recent
currently in RawHide).  Personally, this problem is weird enough to
kind of spook me...  seems they've had busted register spill/reload
logic for a while.

The RawHide GCC 3.0.1 compiler I grabbed doesn't have this problem,
and the rest of the code in that file appears to be correct regardless
of your workaround.  Same with "kgcc".


Do you want me to send this to RedHat?  ...or have you got as good/
better explanation to hand to them already?


--
    Erich Stefan Boleyn     <erich@xxxxxxxx>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"


<Prev in Thread] Current Thread [Next in Thread>