On 9 July 2015 at 02:03, David Malcolm <dmalcolm@redhat.com> 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.
>


Dave

I have attached two new reproducer dumps.

1. The constant fix version has a change that sets the constant value
directly rather than going through the constants table.

2. The NO constant fix version doesn't have this change - this is
failing the test.

The above dumps reflect the removal of the 'base' local variable.

I hope this helps in tracking down what is causing the change.

Regards
Dibyendu