Filed PR jit/66812 for the code generation issue

[David Malcolm]

On Wed, 2015-07-08 at 21:03 -0400, David Malcolm wrote:
> On Wed, 2015-07-08 at 22:54 +0100, Dibyendu Majumdar wrote:
> > Apologies I think the previous description of the flow was incorrect.
> > Here is my second attempt (this is doing my head in so I will stop
> > now):
> 
> [snip detailed analysis of bytecode]
> 
> Thanks.
> 
> So it's basically:
> 
>   * do a bunch of stuff
>   * then set R(1) to boolean false in that last LOADBOOL op
>   * then return
> 
> 
> > 12 [3] LOADBOOL 1 0 0
> > 
> >   (&L->ci->u.l.base[(int)1])->value_.b = (int)0;
> >   (&L->ci->u.l.base[(int)1])->tt_ = (int)1;
> > 
> > Above sets the register 1 to false and this is the return value.
> 
> I've been poring over the dumps:
> https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/
> and I believe the problem is in pass "fre1"; it's eliminating this
> statement for some reason:
>   (&L->ci->u.l.base[(int)1])->value_.b = (int)0;
> 
> so 
>   R1.tt_ = 1 (correct)
> but:
>   R1.value_.i = K0.value_.i  (incorrect, is int 10, not 0)
> 
> The statement is still present at pass 034t.ealias:
> https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/fake.c.034t.ealias
>  
> but is optimized away in pass 035t.fre1:
> https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/fake.c.035t.fre1
> 
> I'll have a more detailed look tomorrow at why fre1 is getting it wrong.
> 
> [snip]

I've managed to create a minimal reproducer for this; see:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66812
where libgccjit miscompiles it, but the C frontend (cc1) handles the
equivalent C code just fine (even at -O3, without needing
-fno-strict-aliasing).

So the next step seems to be to step through the fre1 pass in both
libgccjit and in cc1, and to see what's different.

Yay, progress!

Dave