[Bug target/11087] gcc miscompiles raid1.c from linux kernel

["tst at worldonline dot ch" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11087



------- Additional Comments From tst at worldonline dot ch  2003-10-14 14:19 -------
Ok, what does this mean?
"I've commited this so that it's in before Mark starts rolling tarballs.  I have
not commited the test case from the rhl branches since it doesn't fail without
the patch."
In which version/release the patch is included *and* the tarball is verified,
that the patch is in?
The RH raid1.c workaround was for RH 7.1 kernel 2.4.20 gcc 2.96 and the current
kernel 2.6.0-test7 runs tests with gcc-3.2.2. So i tested gcc 2.95-3, 2.96, 3.3
and the new sources form cvs from yesterday (still open). And everyone crashs in
raid1.c.
I checked out the raid1.c standalone program, and it *never* crashs. So i thinks
it´s not usefull for the testsuite.
However i try to found out, what´s wrong with the alpha assembly code, but i
doesn´t found anything wrong here ( i can´t singlestep the kernel code for
read_balance and the standalone program seems to be fine.)

Code;  fffffc000050dd38 <read_balance+158/280>
0000000000000000 <_PC>:
Code;  fffffc000050dd38 <read_balance+158/280>
   0:   10 00 a6 a0       ldl  t4,16(t5)
Code;  fffffc000050dd3c <read_balance+15c/280>
   4:   1f 04 ff 47       nop
Code;  fffffc000050dd40 <read_balance+160/280>
   8:   24 15 82 40       subq t3,0x10,t3
Code;  fffffc000050dd44 <read_balance+164/280>
   c:   25 31 a0 40       subl t4,0x1,t4
Code;  fffffc000050dd48 <read_balance+168/280>
  10:   00 00 44 a4       ldq  t1,0(t3)
Code;  fffffc000050dd4c <read_balance+16c/280>
  14:   0e 00 40 e4       beq  t1,50 <_PC+0x50> fffffc000050dd88
<read_balance+1a8/280>
Code;  fffffc000050dd50 <read_balance+170/280>   <=====
  18:   58 00 22 a0       ldl  t0,88(t1)   <=====
Code;  fffffc000050dd54 <read_balance+174/280>
  1c:   0c 00 20 e4       beq  t0,50 <_PC+0x50> fffffc000050dd88 

Can anyone tell me, why this code is wrong? $t3 seems to be a valid pointer, but
$t1 got 1 and that fails.
OK - what gcc release i can test with the patch included?

Thanks
Thomas
http://alpha.steudten.com