v1.0.0 Fails to compile C code

[dibyendumajumdar]

Error message is:

number of MIR_PHI operands is less 3

Input was attached file mirbug.c.txt

[vnmakarov]

Thank you for trying it. I hope people will report more bugs for the new version. Although I did a lot of testing, only a feedback from real MIR users will help to create a robust release. After gathering new bugs and fixing them, I can create v1.0.1 and probably remove the unstable release.

As for the test case. I can not reproduce the error. The information is not enough. The file seems unfinished. I tried to make it syntactically correct and add missed function raviV_raise_error (I made it empty). Still I cannot reproduce it.

Could you provide me a standalone test and more info how to reproduce the bug.

[dibyendumajumdar]

Sorry for some reason the file is truncated? I will post a complete version

[dibyendumajumdar]

For reasons I don't know, the redirection to a file is truncated.

Here is the actual code (please replace manually)

static int __ravifunc_1(lua_State *L) {
int raviX__error_code = 0;
int result = 0;
CallInfo *ci = L->ci;
LClosure *cl = clLvalue(ci->func);
TValue *k = cl->p->k;
StkId base = ci->u.l.base;
lua_Integer raviX__i_0 = 0, raviX__i_1 = 0;
TValue ival0; settt_(&ival0, LUA_TNUMINT);
TValue fval0; settt_(&fval0, LUA_TNUMFLT);
TValue bval0; settt_(&bval0, LUA_TBOOLEAN);
TValue ival1; settt_(&ival1, LUA_TNUMINT);
TValue fval1; settt_(&fval1, LUA_TNUMFLT);
TValue bval1; settt_(&bval1, LUA_TBOOLEAN);
TValue ival2; settt_(&ival2, LUA_TNUMINT);
TValue fval2; settt_(&fval2, LUA_TNUMFLT);
TValue bval2; settt_(&bval2, LUA_TBOOLEAN);
TValue nilval; setnilvalue(&nilval);
L0:
// MOVi {1 Kint(0)} {Tint(0)}
raviX__i_0 = 1;
// MOVi {2 Kint(1)} {Tint(1)}
raviX__i_1 = 2;
// MOV {Tint(0)} {T(0)}
{
 TValue *dst_reg = R(0);
 setivalue(dst_reg, raviX__i_0);
}
// CBR {T(0)} {L3, L2}
{
const TValue *src_reg = R(0);
if (!l_isfalse(src_reg)) goto L3;
else goto L2;
}
L1:
 return result;
Lraise_error:
 raviV_raise_error(L, raviX__error_code); /* does not return */
 return result;
L2:
// MOV {Tint(1)} {T(0)}
{
 TValue *dst_reg = R(0);
 setivalue(dst_reg, raviX__i_1);
}
// BR {L3}
goto L3;
L3:
// RET {T(0)} {L1}
{
 TValue *stackbase = ci->func;
 int wanted = ci->nresults;
 result = wanted == -1 ? 0 : 1;
 int available = 1;
 if (wanted == -1) wanted = available;
 int j = 0;
 if (0 < available) {
{
 const TValue *src_reg = R(0);
 TValue *dst_reg = S(0);
 dst_reg->tt_ = src_reg->tt_;
 dst_reg->value_.n = src_reg->value_.n;
}
 }
 j++;
 while (j < wanted) {
  setnilvalue(S(j));
  j++;
 }
 L->top = S(0) + wanted;
 L->ci = ci->previous;
}
goto L1;
}
EXPORT LClosure *__luachunk_0(lua_State *L) {
 LClosure *cl = luaF_newLclosure(L, 1);
 setclLvalue(L, L->top, cl);
 luaD_inctop(L);
 cl->p = luaF_newproto(L);
 Proto *f = cl->p;
 f->ravi_jit.jit_function = __ravifunc_1;
 f->ravi_jit.jit_status = RAVI_JIT_COMPILED;
 f->numparams = 0;
 f->is_vararg = 0;
 f->maxstacksize = 1;
 f->k = luaM_newvector(L, 0, TValue);
 f->sizek = 0;
 for (int i = 0; i < 0; i++)
  setnilvalue(&f->k[i]);
 f->upvalues = luaM_newvector(L, 1, Upvaldesc);
 f->sizeupvalues = 1;
 f->upvalues[0].instack = 1;
 f->upvalues[0].idx = 0;
 f->upvalues[0].name = NULL; // _ENV
 f->upvalues[0].usertype = NULL;
 f->upvalues[0].ravi_type = 128;
 return cl;
}

mirbug.c.txt

[dibyendumajumdar]

Thank you for trying it. I hope people will report more bugs for the new version. Although I did a lot of testing, only a feedback from real MIR users will help to create a robust release. After gathering new bugs and fixing them, I can create v1.0.1 and probably remove the unstable release.

I will run all the tests and report failures. This one is good as it failed to compile. Main Lua test crashed with an assertion - which may be harder to debug, as the failure occurred during execution.

[vnmakarov]

I reproduced it and fixed it by b02f955c9d23170ea539d6e955ca4718f83d37ea. The problem was in a pass doing bb clones.

[dibyendumajumdar]

Thank you - this has improved things a lot, but I have some tests that are failing at execution time, those are harder to debug. I will open an issue once I can narrow it down.