Weird problem

[David Malcolm]

On Mon, 2015-06-29 at 21:49 +0100, Dibyendu Majumdar wrote:
> Hi Dave,
> 
> I am trying to debug a problem I am having with one piece of code.
> 
> The generated code (snippet) is shown below:
> 
>   double OP_RAVI_TOFLT_n_2_8;
>   bool comparison_0_12;
>   comparison_0_12 = luaV_tonumber_ (&base[(int)0],
> &OP_RAVI_TOFLT_n_2_8) == (int)0;
>   if (comparison_0_12) goto OP_RAVI_TOFLT_if_conversion_failed_2_13;
> else goto OP_RAVI_TOFLT_if_conversion_ok_2_14;
> 
> OP_RAVI_TOFLT_if_conversion_ok_2_14:
>   (void)printf ("number ok = %f\
> ", OP_RAVI_TOFLT_n_2_8);
> 
> 
> The printf output says that value of OP_RAVI_TOFLT_n_2_8 is 0.0.
> Yet the called function luaV_tonumber_() set this to a different value:
> 
> Output from luaV_tonumber_():
> 
> set *0x7ffe1bb8d298 to 5.600000
> 
> Output from JIT code above:
> 
> number ok = 0.000000
> 
> From the dump it seems that the address of the local variable
> OP_RAVI_TOFLT_n_2_8 is being passed to the function. And yet the value
> of the variable is its original value which was 0.0.
> 
> Any tips on what I should be looking for?

Looking at src/lvm.c, I see that the signature of luaV_tonumber and that
lua_Number can be various types, including "double".
  int luaV_tonumber_ (const TValue *obj, lua_Number *n)

Does the type signature of luaV_tonumber as compiled by the main
compiler agree with that supplied by gcc_jit_context_new_function?  If
one of them is e.g. expecting a float *, but the other is expecting a
double *, then you might get the symptoms you're seeing.

It might be worth running your code under gdb and putting a breakpoint
on the jitted code; see:
https://gcc.gnu.org/onlinedocs/jit/topics/locations.html#faking-it
and set:
gcc_jit_context_set_bool_option (
  ctxt,
  GCC_JIT_BOOL_OPTION_DEBUGINFO,
  1);

You can then step through it, and through the call to luaV_tonumber_ to
see exactly what's being written; you can go back up the callstack to
see if/when the local is modified.

If that doesn't highlight a cause, maybe you're running into a libgccjit
bug.  If so, can you generate a reproducer and post it here so I can
poke at it please?

Does it help if you introduce an intermediate to hold the result of the
call to luaV_tonumber_ before comparing it against zero?  It
*shouldn't*, but maybe we have a libgccjit bug.

Dave