Re: Re: Miscompilation at -O2

On Fri, Oct 18, 2013 at 1:31 PM, Camm Maguire <camm@maguirefamily.org> wrote:

Greetings, and thanks for your reply! I can try to get a simpler
example, but first let me try to simplify the post, to see if that
illumines the issue by itself. My comments after //

Breakpoint 4, 0x00000000004c1f72 in LI46 (V457=0x60000000047b1258,
V458=0x60000000040400e0 <Cnil_body>) at gcl_cmpfun.c:2657
2657 V459= (*(LnkLI268))((V458),((object)VV[165]));
1: x/i $pc
=> 0x4c1f72 <LI46+242>: br.call.sptk.many b0=b6;;

=============================================================================
// Here is the call to *LnkLI268
=============================================================================

(gdb) ni
0x00000000004c1f80 2657 V459= (*(LnkLI268))((V458),((object)VV[165]));
1: x/i $pc
=> 0x4c1f80 <LI46+256>: [MMI] mov r14=r8

R14 <- R8

So R14 and R8 should be the same.

(gdb) ni
0x00000000004c1f81 2657 V459= (*(LnkLI268))((V458),((object)VV[165]));
1: x/i $pc
=> 0x4c1f81 <LI46+257>: mov r1=r40
(gdb)
2661 {object V460 = (*(LnkLI250))((V459));
1: x/i $pc
=> 0x4c1f82 <LI46+258>: mov r41=r8;;

R41 <- R8 as well here.

So R8 == R14 == R41.

(gdb)
2658 if(((V459))==Cnil){
1: x/i $pc
=> 0x4c1f90 <LI46+272>: [MMI] cmp.eq p6,p7=r8,r14

Now `cmp.eq` R8 does equal R14 here, doesn't it? This would make p6 = 1 and p7 = 0

This clearly isn't doing the comparison you were hoping for since this is always true.

(gdb) i reg r14
r14 0x6000000004af3450 6917529027719672912
(gdb) i reg r1
r1 0x600000000001921c 6917529027641184796
(gdb) i reg r41
r41 0x6000000004af3450 6917529027719672912
(gdb) p V459
$45 = (object) 0x6000000004af3450

=============================================================================
// Here is the return of 0x6000000004af3450 to V459.
// Cnil is 0x60000000040400e0, so the comparison on 2658 should fail
=============================================================================

In your first message you wrote:

if(((V459))==((object)&Cnil_body)){

But here I see:

if(((V459))==Cnil){

OK, so what exactly is going on here? Is Cnil / Cnil_body a constant value (address of a function) and V459 some function pointer variable it is being compared against? If so, then I would say it is generating the wrong code. Notice that:

V459 == 0x6000000004af3450 == r41 == r14 == r8

It should be loading the value of Cnil / Cnil_body (const) to do the comparison, instead it's comparing a register against another register it just copied from!

(gdb) ni
2661 {object V460 = (*(LnkLI250))((V459));
1: x/i $pc
=> 0x4c1f91 <LI46+273>: nop.m 0x0
(gdb)
0x00000000004c1f92 2661 {object V460 = (*(LnkLI250))((V459));
1: x/i $pc
=> 0x4c1f92 <LI46+274>: addl r18=71588,r1;;
(gdb)
2667 VMR46(V461)}}
1: x/i $pc
=> 0x4c1fa0 <LI46+288>: [MIB] (p06) st8 [r34]=r37

This uses p06, which is 1, so this store should happen.

(gdb)
2658 if(((V459))==Cnil){
1: x/i $pc
=> 0x4c1fa1 <LI46+289>: nop.i 0x0
(gdb)
0x00000000004c1fa2 2658 if(((V459))==Cnil){
1: x/i $pc
=> 0x4c1fa2 <LI46+290>: (p06) br.cond.dpnt.few 0x4c2080 <LI46+512>;;
(gdb)

This uses p06, which is 1, so this branch is taken.

=============================================================================
// Here is the comparison that should fail, but jumps over the
// following code instead returning V459 from the function. *LnkLI250 is
// never called.
=============================================================================

2670 }
1: x/i $pc
=> 0x4c2080 <LI46+512>: [MII] nop.m 0x0
(gdb) ni
0x00000000004c2081 2670 }
1: x/i $pc
=> 0x4c2081 <LI46+513>: mov.i ar.pfs=r39
(gdb)
0x00000000004c2082 2670 }
1: x/i $pc
=> 0x4c2082 <LI46+514>: nop.i 0x0;;
(gdb)
0x00000000004c2090 2670 }
1: x/i $pc
=> 0x4c2090 <LI46+528>: [MIB] nop.m 0x0
(gdb)
0x00000000004c2091 2670 }
1: x/i $pc
=> 0x4c2091 <LI46+529>: mov b0=r38
(gdb)
0x00000000004c2092 2670 }
1: x/i $pc
=> 0x4c2092 <LI46+530>: br.ret.sptk.many b0;;
(gdb)

Please let me know if this helps.

This helps to an extent, but a test case would be better. This code looks almost machine generated (variable names/labels are mechnical-looking), and it's hard to grasp without full context; but the disassembly is huge by itself to just "read". I think I have made sense of it, and I think I would agree. I bet this (and perhaps another bug, yet unknown) is the cause of some ia64 weirdness.

Take care,
--
Camm Maguire camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah