incorrect behavior in memory.grow

[kavoc-brown]

Describe the bug

In the fast interpreter with memory64 enabled, memory.grow incorrectly truncates the 64-bit delta to 32 bits. When the delta exceeds UINT32_MAX (e.g., 0x1_0000_0000 pages), the truncation turns it into 0, so the grow is treated as a no-op and the instruction returns the previous page count instead of the failure code.

Version

WAMR 2.4.3, fast interpreter, memory64 enabled (-DWAMR_BUILD_MEMORY64=1), Ubuntu 22.04 (x86-64)

To Reproduce

Build WAMR fast interpreter with memory64 enabled:

cd product-mini/platforms/linux
rm -rf build && mkdir build && cd build
cmake .. -DWAMR_BUILD_MEMORY64=1
make -j"$(nproc)"

Assemble and run the module:

;; save as grow.wat
(module
  (memory i64 1 1)
  (func (export "grow") (result i64)
    (i64.const 4294967296)
    memory.grow)
  (func (export "size") (result i64)
    memory.size))

wasm-tools validate grow.wat
wat2wasm grow.wat -o grow.wasm
iwasm -f grow grow.wasm

See error: the interpreter prints 0x1:i64 (previous page count), i.e., it reports success instead of failure.

Expected behavior

-1 for failure

Actual Result

0x1:i64

Additional context

WASM_OP_MEMORY_GROW reads the delta via a 32-bit path (e.g., frame_lp[...]/uint32), losing high bits before calling wasm_enlarge_memory() (which currently accepts a uint32). The result is also written back through a 32-bit slot, even when the instruction’s result type is i64 under memory64.

[TianlongLiang]

The same root cause as discussed in https://github.com/bytecodealliance/wasm-micro-runtime/issues/4689