[JSC] IPInt slow path for `memory.atomic.notify` truncates the Memory64 pointer and offset to 32 bits

afc44e3

Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp

 WASM_IPINT_EXTERN_CPP_DECL(memory_atomic_notify, IPIntStackEntry* args)
 {
 #if CPU(ARM64) || CPU(X86_64)
-    unsigned offset = args[0].i32;
+    uint64_t offset = args[0].i64;
     uint8_t memoryIndex = args[1].i32;
     int32_t count = args[2].i32;
-    unsigned base = args[3].i32;
+    uint64_t base = args[3].i64;
     int32_t result = Wasm::memoryAtomicNotify(instance, base, offset, count, memoryIndex);

JSTests/wasm/stress/memory64-atomic-notify-out-of-bounds.js

+assert.throws(() => exports.notify(0x1_0000_0000n), WebAssembly.RuntimeError, "Out of bounds memory access");
+assert.throws(() => exports.notify(0xffff_ffff_ffff_ffffn), WebAssembly.RuntimeError, "Out of bounds memory access");
+assert.eq(exports.notify(0n), 0);

For instructions that cannot be handled inline by IPInt's assembly fast path, IPInt falls back to C++ "slow path" functions. Arguments are passed through an IPIntStackEntry union with both .i32 and .i64 members sharing the same storage — reading the wrong member silently drops the upper bits without any runtime error. Memory64 extends linear memory addressing to 64 bits.

This commit fixes the IPInt C++ slow path for memory.atomic.notify, which read the 64-bit address operand and immediate offset via the .i32 union member of IPIntStackEntry, silently truncating both to 32 bits. The fix changes both reads to .i64. Because the assembly fast path correctly passes full 64-bit values, the bug was invisible to Memory32 modules and only manifested when a Memory64 address had its upper 32 bits set.

Significance

Reading a 64-bit address through IPIntStackEntry's .i32 union member silently dropped the upper 32 bits; pointer 0x1_0000_0000n aliased to address 0 and memory.atomic.notify operated on linear memory's first slot instead of trapping.

Audit directions

All other atomic and Memory64-capable slow paths in WasmIPIntSlowPaths.cpp. The .i32-vs-.i64 union mismatch is a mechanical pattern that copy-pastes badly. Audit memory_atomic_wait32, memory_atomic_wait64, every atomic.rmw.*, atomic.store, atomic.load, and any other Memory64-capable memory instruction slow path for the same shape.
memoryIndex and count field types. Verify the fix's choice to leave these as .i32 is correct against what the assembly fast path actually pushes — a sister mismatch in either field would produce its own truncation primitive.