Filed PR jit/66812 for the code generation issue

[Dibyendu Majumdar]

On 9 July 2015 at 20:22, David Malcolm <dmalcolm@redhat.com> wrote:
>> but it does seem to have caused
>> the optimization bug to go away - i.e. the tests now pass. I will run
>> more tests tomorrow to see if this is true under all optimization
>> settings.
>
> FWIW, I suspect that this is effectively just papering over the problem,
> and that it will come back to bite us, just with a more complicated
> reproducer :(
>

Yes agree.

> Does something like:

>
>
> function x(some_arg)
>   local IX
>   if ((some_arg or true) and false) then
>     IX = true
>   end;
>   return ((some_arg or true) and false)
> end
> assert(x() == false)
>
>
>
> exhibit the bug?  (have never programmed Lua, so this probably even
> isn't syntactically correct, but hopefully you get the idea, with
> const-propagation of 10's value and typecode lots of code gets optimized
> away, so using an arg of unknown type to thwart that and hopefully get
> the bug to re-manifest itself).
>

Actually that is valid Lua. Since you aren't passing a value to x()
then some_arg will be NIL. In Lua, NIL and false are false, everything
else is true.
The example above works okay as is, and also when I pass 10 to x().
As usual with certain bugs - only a specific set of circumstances trigger it.

>
> (Note that I've managed to isolate a minimal reproducer for the problem,
> as noted in another mail this thread)
>

Yes that is very good news. Hope you will soon discover the root cause.

Thanks and Regards
Dibyendu