`Wasmer's` execution leads to `LLVM Crash`

[Theaamadu]

Describe the bug

I have generated a testcase and executed it with Wasmer's llvm backend mode runtime, and it reports a function return type mismatch leading to an LLVM ERROR crash.

wasmer 6.0.0 (9ef4e4e 2025-06-27)
binary: wasmer-cli
commit-hash: 9ef4e4e7382b53c06aaadf4aa864b726c4851dc3
commit-date: 2025-06-27
host: x86_64-unknown-linux-gnu
runtimes: singlepass, cranelift, llvm
rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

Steps to reproduce

Test case:

(module
  (type (;0;) (func (result i32 i32 v128)))
  (export "main" (func 0))
  (func (;0;) (type 0) (result i32 i32 v128)
    i32.const 0
    i32.const 0
    v128.const i32x4 0x00000000 0x00000000 0x00000000 0x00000000
  )
)

Steps to reproduce:

1. Convert wat to wasm.
2. Run: wasmer run --enable-simd --enable-threads --enable-verifier --enable-reference-types --enable-multi-value --enable-bulk-memory --enable-relaxed-simd --enable-extended-const --llvm shrunken_test837579.wasm --invoke main

Expected behavior

Should output 0 0 0

Actual behavior

Outputs:

Function return type does not match operand type of return inst!
  ret void
 { i64, i128 }LLVM ERROR: Broken module found, compilation aborted!
Aborted

Additional context

Here is a partial stack trace:

* thread #768, name = 'wasmer', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff7c969fc libc.so.6`__GI___pthread_kill at pthread_kill.c:44:76
    frame #1: 0x00007ffff7c969b0 libc.so.6`__GI___pthread_kill [inlined] __pthread_kill_internal(signo=6, threadid=140686095439424) at pthread_kill.c:78:10
    frame #2: 0x00007ffff7c969b0 libc.so.6`__GI___pthread_kill(threadid=140686095439424, signo=6) at pthread_kill.c:89:10
    frame #3: 0x00007ffff7c42476 libc.so.6`__GI_raise(sig=6) at raise.c:26:13
    frame #4: 0x00007ffff7c287f3 libc.so.6`__GI_abort at abort.c:79:7
    frame #5: 0x000055555a451c85 wasmer`llvm::report_fatal_error(llvm::Twine const&, bool) + 437
    frame #6: 0x000055555a451ac6 wasmer`llvm::report_fatal_error(char const*, bool) + 38
    frame #7: 0x000055555a3e073d wasmer`llvm::VerifierPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 173
    frame #8: 0x00005555591ed72d wasmer`llvm::detail::PassModel<llvm::Module, llvm::VerifierPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 13
    frame #9: 0x000055555a3bd6f4 wasmer`llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 372
    frame #10: 0x00005555591ec00a wasmer`LLVMRunPasses + 794
    frame #11: 0x0000555558f643d8 wasmer`inkwell::module::Module::run_passes::hfeaedc9c1ae42541(self=0x00007ff408bdeb98, passes=(data_ptr = "verify,sccp,early-cse,adce,sroa,aggressive-instcombine,jump-threading,simplifycfg,reassociate,loop-rotate,indvars,sccp,reassociate,simplifycfg,gvn,memcpyopt,dse,dce,reassociate,simplifycfg,mem2reg", length = 196), machine=0x00007ff408be2858, options=(options_ref = 0x00007ff39401e270)) at module.rs:1507:25
    frame #12: 0x0000555558d5ea86 wasmer`wasmer_compiler_llvm::translator::code::FuncTranslator::translate_to_module::h8baf837d6cd5713b(self=0x00007ff408be2828, wasm_module=0x000055555fab9520, module_translation=0x00007ffffffe8ab8, local_func_index=0x00007ff394000c60, function_body=0x000055555fab1ad0, config=0x000055555fa5a350, memory_styles=0x00007ffffffe9e80, _table_styles=0x00007ffffffe9e98, symbol_registry=&dyn wasmer_compiler::types::symbols::SymbolRegistry @ 0x00007ff408be0b38) at code.rs:373:9
    frame #13: 0x0000555558d60137 wasmer`wasmer_compiler_llvm::translator::code::FuncTranslator::translate::hdbd5751f317fd19a(self=0x00007ff408be2828, wasm_module=0x000055555fab9520, module_translation=0x00007ffffffe8ab8, local_func_index=0x00007ff394000c60, function_body=0x000055555fab1ad0, config=0x000055555fa5a350, memory_styles=0x00007ffffffe9e80, table_styles=0x00007ffffffe9e98, symbol_registry=&dyn wasmer_compiler::types::symbols::SymbolRegistry @ 0x00007ff408be1110) at code.rs:408:22
    frame #14: 0x0000555558e3abd2 wasmer`_$LT$wasmer_compiler_llvm..compiler..LLVMCompiler$u20$as$u20$wasmer_compiler..compiler..Compiler$GT$::compile_module::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h3e500747579bebc9(func_translator=0x00007ff408be2828, (null)=0x00007ff394000c60) at compiler.rs:372:29
    frame #15: 0x0000555558e38f8d wasmer`core::ops::function::impls::_$LT$impl$u20$core..ops..function..Fn$LT$A$GT$$u20$for$u20$$RF$F$GT$::call::hc8d0be449fa24ba2(self=0x00007ff408be2478, args=(&mut wasmer_compiler_llvm::translator::code::FuncTranslator, &(wasmer_types::indexes::LocalFunctionIndex, &wasmer_compiler::translator::environ::FunctionBodyData)) @ 0x00007ff408be1290) at function.rs:262:13
    frame #16: 0x0000555558ed13e2 wasmer`_$LT$rayon..iter..map_with..MapWithFolder$LT$C$C$U$C$F$GT$$u20$as$u20$rayon..iter..plumbing..Folder$LT$T$GT$$GT$::consume_iter::with::_$u7b$$u7b$closure$u7d$$u7d$::h9eea531e1bd385ca(x=0x00007ff394000c60) at map_with.rs:317:22
    frame #17: 0x0000555558ed3bc0 wasmer`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$::call_once::h6a9f841cee843a53(self=0x00007ff408be2478, args=(&(wasmer_types::indexes::LocalFunctionIndex, &wasmer_compiler::translator::environ::FunctionBodyData)) @ 0x00007ff408be12d8) at function.rs:305:13
    frame #18: 0x0000555558e6ed50 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h9db9c2ed75bcb029 at option.rs:1110:29
    frame #19: 0x0000555558e6ed06 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h9db9c2ed75bcb029(self=0x00007ff408be2468) at map.rs:108:26
    frame #20: 0x0000555558e6eb39 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h783ee28c912b1f1c(self=0x00007ff408be2468) at map.rs:108:9
    frame #21: 0x0000555558f01987 wasmer`_$LT$core..iter..adapters..take_while..TakeWhile$LT$I$C$P$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::hbd266dcaccec6c13(self=0x00007ff408be2468) at take_while.rs:47:21
    frame #22: 0x0000555558e6efa9 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::he1434a4541b30391(self=0x00007ff408be2468) at map.rs:108:9

I have tested on Ubuntu 22.04 OS and x86_64 CPU.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: None (Theaamadu)

### Describe the bug I have generated a testcase and executed it with Wasmer's llvm backend mode runtime, and it reports a function return type mismatch leading to an `LLVM ERROR` crash.

wasmer 6.0.0 (9ef4e4e 2025-06-27)
binary: wasmer-cli
commit-hash: 9ef4e4e7382b53c06aaadf4aa864b726c4851dc3
commit-date: 2025-06-27
host: x86_64-unknown-linux-gnu
runtimes: singlepass, cranelift, llvm
rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

Steps to reproduce

Test case:

(module
  (type (;0;) (func (result i32 i32 v128)))
  (export "main" (func 0))
  (func (;0;) (type 0) (result i32 i32 v128)
    i32.const 0
    i32.const 0
    v128.const i32x4 0x00000000 0x00000000 0x00000000 0x00000000
  )
)

Steps to reproduce:

1. Convert wat to wasm.
2. Run: wasmer run --enable-simd --enable-threads --enable-verifier --enable-reference-types --enable-multi-value --enable-bulk-memory --enable-relaxed-simd --enable-extended-const --llvm shrunken_test837579.wasm --invoke main

Expected behavior

Should output 0 0 0

Actual behavior

Outputs:

Function return type does not match operand type of return inst!
  ret void
 { i64, i128 }LLVM ERROR: Broken module found, compilation aborted!
Aborted

Additional context

Here is a partial stack trace:

* thread #<!-- -->768, name = 'wasmer', stop reason = signal SIGABRT
  * frame #<!-- -->0: 0x00007ffff7c969fc libc.so.6`__GI___pthread_kill at pthread_kill.c:44:76
    frame #<!-- -->1: 0x00007ffff7c969b0 libc.so.6`__GI___pthread_kill [inlined] __pthread_kill_internal(signo=6, threadid=140686095439424) at pthread_kill.c:78:10
    frame #<!-- -->2: 0x00007ffff7c969b0 libc.so.6`__GI___pthread_kill(threadid=140686095439424, signo=6) at pthread_kill.c:89:10
    frame #<!-- -->3: 0x00007ffff7c42476 libc.so.6`__GI_raise(sig=6) at raise.c:26:13
    frame #<!-- -->4: 0x00007ffff7c287f3 libc.so.6`__GI_abort at abort.c:79:7
    frame #<!-- -->5: 0x000055555a451c85 wasmer`llvm::report_fatal_error(llvm::Twine const&amp;, bool) + 437
    frame #<!-- -->6: 0x000055555a451ac6 wasmer`llvm::report_fatal_error(char const*, bool) + 38
    frame #<!-- -->7: 0x000055555a3e073d wasmer`llvm::VerifierPass::run(llvm::Module&amp;, llvm::AnalysisManager&lt;llvm::Module&gt;&amp;) + 173
    frame #<!-- -->8: 0x00005555591ed72d wasmer`llvm::detail::PassModel&lt;llvm::Module, llvm::VerifierPass, llvm::PreservedAnalyses, llvm::AnalysisManager&lt;llvm::Module&gt; &gt;::run(llvm::Module&amp;, llvm::AnalysisManager&lt;llvm::Module&gt;&amp;) + 13
    frame #<!-- -->9: 0x000055555a3bd6f4 wasmer`llvm::PassManager&lt;llvm::Module, llvm::AnalysisManager&lt;llvm::Module&gt; &gt;::run(llvm::Module&amp;, llvm::AnalysisManager&lt;llvm::Module&gt;&amp;) + 372
    frame #<!-- -->10: 0x00005555591ec00a wasmer`LLVMRunPasses + 794
    frame #<!-- -->11: 0x0000555558f643d8 wasmer`inkwell::module::Module::run_passes::hfeaedc9c1ae42541(self=0x00007ff408bdeb98, passes=(data_ptr = "verify,sccp,early-cse,adce,sroa,aggressive-instcombine,jump-threading,simplifycfg,reassociate,loop-rotate,indvars,sccp,reassociate,simplifycfg,gvn,memcpyopt,dse,dce,reassociate,simplifycfg,mem2reg", length = 196), machine=0x00007ff408be2858, options=(options_ref = 0x00007ff39401e270)) at module.rs:1507:25
    frame #<!-- -->12: 0x0000555558d5ea86 wasmer`wasmer_compiler_llvm::translator::code::FuncTranslator::translate_to_module::h8baf837d6cd5713b(self=0x00007ff408be2828, wasm_module=0x000055555fab9520, module_translation=0x00007ffffffe8ab8, local_func_index=0x00007ff394000c60, function_body=0x000055555fab1ad0, config=0x000055555fa5a350, memory_styles=0x00007ffffffe9e80, _table_styles=0x00007ffffffe9e98, symbol_registry=&amp;dyn wasmer_compiler::types::symbols::SymbolRegistry @ 0x00007ff408be0b38) at code.rs:373:9
    frame #<!-- -->13: 0x0000555558d60137 wasmer`wasmer_compiler_llvm::translator::code::FuncTranslator::translate::hdbd5751f317fd19a(self=0x00007ff408be2828, wasm_module=0x000055555fab9520, module_translation=0x00007ffffffe8ab8, local_func_index=0x00007ff394000c60, function_body=0x000055555fab1ad0, config=0x000055555fa5a350, memory_styles=0x00007ffffffe9e80, table_styles=0x00007ffffffe9e98, symbol_registry=&amp;dyn wasmer_compiler::types::symbols::SymbolRegistry @ 0x00007ff408be1110) at code.rs:408:22
    frame #<!-- -->14: 0x0000555558e3abd2 wasmer`_$LT$wasmer_compiler_llvm..compiler..LLVMCompiler$u20$as$u20$wasmer_compiler..compiler..Compiler$GT$::compile_module::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h3e500747579bebc9(func_translator=0x00007ff408be2828, (null)=0x00007ff394000c60) at compiler.rs:372:29
    frame #<!-- -->15: 0x0000555558e38f8d wasmer`core::ops::function::impls::_$LT$impl$u20$core..ops..function..Fn$LT$A$GT$$u20$for$u20$$RF$F$GT$::call::hc8d0be449fa24ba2(self=0x00007ff408be2478, args=(&amp;mut wasmer_compiler_llvm::translator::code::FuncTranslator, &amp;(wasmer_types::indexes::LocalFunctionIndex, &amp;wasmer_compiler::translator::environ::FunctionBodyData)) @ 0x00007ff408be1290) at function.rs:262:13
    frame #<!-- -->16: 0x0000555558ed13e2 wasmer`_$LT$rayon..iter..map_with..MapWithFolder$LT$C$C$U$C$F$GT$$u20$as$u20$rayon..iter..plumbing..Folder$LT$T$GT$$GT$::consume_iter::with::_$u7b$$u7b$closure$u7d$$u7d$::h9eea531e1bd385ca(x=0x00007ff394000c60) at map_with.rs:317:22
    frame #<!-- -->17: 0x0000555558ed3bc0 wasmer`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$::call_once::h6a9f841cee843a53(self=0x00007ff408be2478, args=(&amp;(wasmer_types::indexes::LocalFunctionIndex, &amp;wasmer_compiler::translator::environ::FunctionBodyData)) @ 0x00007ff408be12d8) at function.rs:305:13
    frame #<!-- -->18: 0x0000555558e6ed50 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h9db9c2ed75bcb029 at option.rs:1110:29
    frame #<!-- -->19: 0x0000555558e6ed06 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h9db9c2ed75bcb029(self=0x00007ff408be2468) at map.rs:108:26
    frame #<!-- -->20: 0x0000555558e6eb39 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h783ee28c912b1f1c(self=0x00007ff408be2468) at map.rs:108:9
    frame #<!-- -->21: 0x0000555558f01987 wasmer`_$LT$core..iter..adapters..take_while..TakeWhile$LT$I$C$P$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::hbd266dcaccec6c13(self=0x00007ff408be2468) at take_while.rs:47:21
    frame #<!-- -->22: 0x0000555558e6efa9 wasmer`_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::he1434a4541b30391(self=0x00007ff408be2468) at map.rs:108:9

I have tested on Ubuntu 22.04 OS and x86_64 CPU.

[dschuff]

I think this bug will probably have to be reported to wasmer. In order for it to be actionable upstream, the reproducer should ideally be in LLVM IR form (or alternatively C if it's a clang+LLVM bug). Without that, we aren't really able to use every possible frontend to reproduce bugs.
Also the error you are seeing ("broken module found") is a module verifier error, suggesting that the module that wasmer is giving LLVM is somehow invalid.
Thirdly (and now I guess I'm nitpicking), this wouldn't actually be a wasm backend bug, because the codegen from wasmer is coming FROM wasm (and presumably compiling to native x86 or whatever), rather than coming from a language frontend and compiling TO wasm.
So, to track it down, I would first figure out what kind of LLVM IR wasmer is producing and see if it's in fact invalid. If so, then it's a wasmer bug. If you think it's actually valid IR, then it would be a bug in LLVM's verifier or some other mid-level pass.

[Theaamadu]

Thanks @dschuff for providing your insight and great info.