libquickjs v0.13.0 is transpiled from QuickJS release 2026-06-04, which
changes the bytecode emitted for the test script:

- The serialized function header gained a var_ref_count field.
- Variable definitions record var_ref_idx instead of scope_level.
- Opcodes were renumbered: push_i8 42; push_i16 314; mul; set_loc0; return
  is now encoded bb 2a bc 3a 01 98 cb 28, previously bd 2a be 3a 01 9a cd 28.

BC_VERSION is unchanged (5), but bytecode produced by an older release no
longer loads, it fails with "SyntaxError: read after the end of the buffer".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

linux/s390x is the only big endian target and there every Javascript integer
crossing into Go decoded as 0: TestEval/eval1 saw int(0) for 42*314, every
example returning a number failed and TestEvalError reported LineNumber 0,
all from the same path.

The transpiled engine is not at fault. ccgo represents the eight bytes wide
JSValueUnion as its widest member, an uint64, and accesses the narrow members
of that union in the value domain: JS_MKVAL zero extends the payload into the
low 32 bits (XNewInt32) and JS_VALUE_GET_INT truncates the uint64 back to 32
bits (JS_ToInt32Free). That is self consistent, so Javascript evaluating
inside the engine is correct on s390x.

The wrapper instead took the payload by address, as the first four bytes of
the union. Those are the low 32 bits on a little endian target only, on s390x
they are the high bits, always zero for an int32 or a boolean. Go through
jsvToInt32/jsvSetInt32 in both value representation files instead. The float64
and pointer payloads are as wide as the union itself, so for those the two
domains coincide and they stay plain casts.

newBool was broken the same way, but invisibly: it wrote the payload where the
decoder read it back, so a Go boolean round tripping through Go looked right
while Javascript itself saw the opposite value. testEval1 would have caught
the read side with "42 < 314", except that t.Fatalf on the int case aborted
the table before reaching it. The new g12..g14 cases in testRegisterGoFuncOK
have Javascript compare a Go boolean and integer with === instead.

Verified on the linux/s390x QEMU VM: go test ./... and the libc.memgrind leak
test both pass there now. linux/amd64 and a natively run linux/386 binary,
which covers quickjs32.go, stay green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>