32 bit JIT error with nightly haxe
As mentioned in https://github.com/HaxeFoundation/haxe/pull/11734#issuecomment-2262487022, 32 bit builds of hashlink fail to run any program and exit with the error:
JIT ERROR 0 (jit.c line 1242)
Here is the line where the error is coming from: https://github.com/HaxeFoundation/hashlink/blob/9888913ed2e1eef9fc03085100c92bd44985c781/src/jit.c#L1242
This only came up on the CMake build (which has since been disabled), but it also affects the vs2019 build, it's just that those builds don't run any tests.
This patch seems to avoid the error, but I'm not sure if it's correct:
diff --git a/src/jit.c b/src/jit.c
index 7571090..b971f85 100644
--- a/src/jit.c
+++ b/src/jit.c
@@ -1238,7 +1238,7 @@ static void store( jit_ctx *ctx, vreg *r, preg *v, bool bind ) {
r->current = NULL;
}
v = copy(ctx,&r->stack,v,r->size);
- if( IS_FLOAT(r) != (v->kind == RFPU) )
+ if( (IS_FLOAT(r) || (!IS_64 && r->t->kind == HI64)) != (v->kind == RFPU) )^M
ASSERT(0);
if( bind && r->current != v && (v->kind == RCPU || v->kind == RFPU) ) {
scratch(v);
Perhaps a better patch would be:
diff --git a/src/jit.c b/src/jit.c
index 535ab69..c55c749 100644
--- a/src/jit.c
+++ b/src/jit.c
@@ -3760,6 +3760,11 @@ int hl_jit_function( jit_ctx *ctx, hl_module *m, hl_function *f ) {
break;
case OGetMem:
{
+ #ifndef HL_64
+ if (dst->t->kind == HI64) {
+ error_i64();
+ }
+ #endif
preg *base = alloc_cpu(ctx, ra, true);
preg *offset = alloc_cpu64(ctx, rb, true);
store(ctx, dst, pmem2(&p,base->id,offset->id,1,0), false);
This causes this more descriptive error, which is what happens later on when applied the previous patch too:
The module you are loading is using 64 bit ints that are not supported by the HL32.
Please run using HL64 or compile with -D hl-legacy32
The existing code is a bit confusing, it looks like in some parts the 32 bit jit gives an error if it comes across i64, and in other parts it emulates it using floating point arithmetic.
Also, there is also a problem because the haxe commit that was linked does not respect hl-legacy32 and adds i64 arrays to the build even if hl-legacy32 is added.
The hl-legacy32 flag is now respected again, and this is tested thanks to #783