This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
optimization/732: Code generation bug on alpha 21264 at -O2
- To: gcc-gnats at gcc dot gnu dot org
- Subject: optimization/732: Code generation bug on alpha 21264 at -O2
- From: lucier at math dot purdue dot edu
- Date: 3 Nov 2000 16:22:43 -0000
- Cc: feeley at iro dot umontreal dot ca
- Reply-To: lucier at math dot purdue dot edu
- Resent-Cc: gcc-prs at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, feeley at iro dot umontreal dot ca
- Resent-Reply-To: gcc-gnats@gcc.gnu.org, lucier@math.purdue.edu
>Number: 732
>Category: optimization
>Synopsis: Code generation bug on alpha 21264 at -O2
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Fri Nov 03 08:26:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: B. Lucier
>Release: gcc version 2.97 20001102 (experimental)
>Organization:
>Environment:
alphaev6-unknown-linux-gnu
>Description:
With this compiler
popov-19% gcc -v
Reading specs from /export/u10/egcs-test/lib/gcc-lib/alphaev6-unknown-linux-gnu/2.97/specs
Configured with: --prefix=/export/u10/egcs-test --enable-checking=no
gcc version 2.97 20001102 (experimental)
on this code
http://www.math.purdue.edu/~lucier/_io.i.gz
with these options:
gcc -save-temps -g -Wall -W -Wno-unused -O2 -mieee -fno-math-errno -mcpu=ev6 -Wdisabled-optimization -c -I. -D___PRIMAL -D___LIBRARY -D___DEBUG_STACK_LIMIT -D___DEBUG_HEAP_LIMIT -D___DEBUG_GARBAGE_COLLECT -D___DEBUG_ALLOC_MEM -D___SINGLE_HOST -Dshow_descr -fno-strict-aliasing _io.c; \
for the first of these lines of code:
___jump: {void *___host_label=((___label_struct*)(___pc-1))->host_label; if (((___label_struct*)(___pc-1))->host == ___H__20___io) goto *___host_label;} ___jumpext:
___ps->pc=___pc; ___ps->hp=___hp; ___ps->fp=___fp; ___ps->r[0]=___r0; ___ps->r[1]=___r1; ___ps->r[2]=___r2; ___ps->r[3]=___r3; ___ps->r[4]=___r4; return ___pc; }
the following code is generated:
$LBB4:
$L2259:
$LM240:
.stabn 68,0,34665,$LM240
ldq $1,23($13)
lda $2,___H__20___io
ldq $3,15($13)
cmpeq $1,$2,$1
beq $1,$L2255
ldq $13,0($14)
lda $1,2($9)
ldq $2,71($9)
jmp $31,($3),0
or, from gdb 5.0:
(gdb) info line
Line 34665 of "_io.c" starts at address 0x1200a18cc <___H__20___io+1516>
and ends at 0x1200a18f0 <___H__20___io+1552>.
(gdb) disassem 0x1200a18cc 0x1200a18f0
Dump of assembler code from 0x1200a18cc to 0x1200a18f0:
0x1200a18cc <___H__20___io+1516>: ldq t0,23(s4)
0x1200a18d0 <___H__20___io+1520>: ldq t1,-14232(gp)
0x1200a18d4 <___H__20___io+1524>: ldq t2,15(s4)
0x1200a18d8 <___H__20___io+1528>: cmpeq t0,t1,t0
0x1200a18dc <___H__20___io+1532>: beq t0,0x1200a1370 <___H__20___io+144>
0x1200a18e0 <___H__20___io+1536>: ldq s4,0(s5)
0x1200a18e4 <___H__20___io+1540>: lda t0,2(s0)
0x1200a18e8 <___H__20___io+1544>: ldq t1,71(s0)
0x1200a18ec <___H__20___io+1548>: jmp zero,(t2),0x1200a18f0 <___H__20___io+1552>
Just before this code is executed, these are the register values:
(gdb) info reg
v0 0x12028e231 4834517553
t0 0x3 3
t1 0x0 0
t2 0x1200b0c10 4832562192
t3 0x10 16
t4 0x200009784f0 2199033185520
t5 0x12028df31 4834516785
t6 0x12028e0b1 4834517169
t7 0x1202746e8 4834412264
s0 0xc0 192
s1 0x0 0
s2 0x1202835d1 4834473425
s3 0x12027b6b1 4834440881
s4 0x1202835d1 4834473425
s5 0x1202caea0 4834766496
fp 0x200009f7f58 2199033708376
a0 0x12028e471 4834518129
a1 0x12028e411 4834518033
a2 0x12028e3b1 4834517937
a3 0x12028e351 4834517841
a4 0x0 0
a5 0x20000978471 2199033185393
t8 0x12028e651 4834518609
t9 0x12028e5f1 4834518513
t10 0x12028e111 4834517265
t11 0x12028e2f1 4834517745
ra 0x12004bda0 4832148896
t12 0x12028e4d1 4834518225
at 0x12028e291 4834517649
gp 0x1202ce0b0 4834779312
sp 0x11ffff5b0 4831835568
zero 0x0 0
fpcr 0xe90e000000200000 -1653384013196296192
pc 0x1200a18cc 4832499916
vfp 0x11ffff660 4831835744
Note that the value of s0 ($9) is not valid memory pointer; note also
that the instructions between the beq and the jmp are totally compiler
generated, they are not generated from the local source code at all.
So when I step, I get:
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x1200a18e8 in ___H__20___io (___ps=0x1202caea0) at _io.c:34665
34665 ___END_M_SW
(gdb) info reg
v0 0x12028e231 4834517553
t0 0xc2 194
t1 0x1200a12e0 4832498400
t2 0x1200b0c20 4832562208
t3 0x10 16
t4 0x200009784f0 2199033185520
t5 0x12028df31 4834516785
t6 0x12028e0b1 4834517169
t7 0x1202746e8 4834412264
s0 0xc0 192
s1 0x0 0
s2 0x1202835d1 4834473425
s3 0x12027b6b1 4834440881
s4 0x200009e1038 2199033614392
s5 0x1202caea0 4834766496
fp 0x200009f7f58 2199033708376
a0 0x12028e471 4834518129
a1 0x12028e411 4834518033
a2 0x12028e3b1 4834517937
a3 0x12028e351 4834517841
a4 0x0 0
a5 0x20000978471 2199033185393
t8 0x12028e651 4834518609
t9 0x12028e5f1 4834518513
t10 0x12028e111 4834517265
t11 0x12028e2f1 4834517745
ra 0x12004bda0 4832148896
t12 0x12028e4d1 4834518225
at 0x12028e291 4834517649
gp 0x1202ce0b0 4834779312
sp 0x11ffff5b0 4831835568
zero 0x0 0
fpcr 0xe90e000000200000 -1653384013196296192
pc 0x1200a18e8 4832499944
vfp 0x11ffff660 4831835744
So you can see that
0x1200a18e0 <___H__20___io+1536>: ldq s4,0(s5)
was executed (the value of s4 is now different from the value of s2),
and it is segfaulting on the first load from
0x1200a18e4 <___H__20___io+1540>: lda t0,2(s0)
0x1200a18e8 <___H__20___io+1544>: ldq t1,71(s0)
My guess is that this code is generated in gcse; the same source code
in _kernel.c generates
.stabn 68,0,7357,$LM70
ldq $1,23($4)
lda $2,___H__20___kernel
ldq $3,15($4)
cmpeq $1,$2,$1
beq $1,$L408
jmp $31,($3),0
which is more or less a direct translation of the C code and is executed
correctly before I got to the breakpoint in _io.c.
I'm sorry I can't offer you a smaller test case, but after three days
of debugging, this is as far as I got.
Brad Lucier
>How-To-Repeat:
>Fix:
I wish I knew.
>Release-Note:
>Audit-Trail:
>Unformatted: