Wenyong Huang

Hi, thanks for reporting the issue. I did some experiment, it is caused by the meta data setting to the llvm fmul intrinsic, if I changed it from "fpexpect.strict" to...

The LLVM-JIT leverages LLVM framework while FAST-JIT's framework is self-implemented in WAMR, their pipelines and codegens are different, so the result may be different, sometimes we have to check the...

@erxiaozhou thanks for reporting the issue, it is mainly caused by the handling of an if block without else opcode for fast interpreter: ```wast if (param i32 i32) (result i32...

Hi, I have no idea about the difference between the AOT files generated for `gnu` and `eabi` either, it seems that even for `eabi`, the generated machine code is different...

Maybe the second way is better, since the issue not only occurs in the host function, but also may occur in runtime, .e.g. allocating argv buffer in wasm_runtime_invoke_native: https://github.com/bytecodealliance/wasm-micro-runtime/blob/30426be82c806391c9709c5c11c891cdf50b528f/core/iwasm/common/wasm_runtime_common.c#L4916-L4921 It...

OK, and it would be good if we also fix the argv buffer allocation issue in wasm_runtime_invoke_native.

Close the issue since it was fixed.

@OkannShn thanks for the reminding, I added `CONFIG_LOG_BUFFER_SIZE=4096` in https://github.com/bytecodealliance/wasm-micro-runtime/pull/3370.

@iKlask The symbol name of windows 32 may start with '_', so "_aot_stack_sizes" should be same as "aot_stack_sizes" in windows/linux 64, since the relocation for the latter is redirected into...

Yes, they are the same, "aot_stack_sizes" is the name of an internal global array and the array is put into a data section named ".aot_stack_sizes", and the aot code accesses...