LLVM -Og leads to invalid wasm (bad drop/fallthru)

[poretga99]

We have issues when compiling our source code with some debug information. If we build in Release mode without additional debugging flags, everything is working just fine.

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.13 (2659582)

Error log

[wasm-validator error in function __original_main] unexpected false: non-final block elements returning a value must be dropped, on 
(block (result i32)
 (call $__pthread_self_internal)
 (i64.const 2)
 (i32.const 0)
)
(on index 0:
0x40d0c360310
), type: i64
[wasm-validator error in function __original_main] unexpected false: non-final block elements returning a value must be dropped, on 
(block (result i32)
 (call $__pthread_self_internal)
 (i64.const 2)
 (i32.const 0)
)
(on index 1:
0x40d0c360358
), type: i64
Fatal: error validating input
em++: error: '/emsdk/upstream/bin/wasm-opt --print-function-map main.wasm --mvp-features --enable-bulk-memory --enable-bulk-memory-opt --enable-call-indirect-overlong --enable-memory64 --enable-multivalue --enable-mutable-globals --enable-nontrapping-float-to-int --enable-reference-types --enable-sign-ext' failed (returned 1)

Simple reproducer
mkdir build && cd build && emcmake cmake .. -DCMAKE_BUILD_TYPE=Release && cmake --build .

// cat main.cpp
#include <emscripten/bind.h>

int main() {
    emscripten::val a;
    return a.isNull();
}

# cat CMakeLists.txt
project(reproducer LANGUAGES CXX)
 
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
option(ENABLE_WASM64 OFF)
 
add_executable(main main.cpp)
target_compile_options(main PRIVATE -Og -sMEMORY64=1)
target_link_options(main PRIVATE -Og --bind --emit-symbol-map -sMEMORY64=1)

[sbc100]

Can you show the full failing em++ command? (you might need to add --verbose to your --build command, or switch to using ninja (which shows failing commands by default).

[kripken]

I followed the steps here but could not reproduce an error on current trunk. Possibly this has been fixed since 4.0.13?

[poretga99]

The whole command is as follows:

/emsdk/upstream/emscripten/em++ -O3 -DNDEBUG -Og --bind --emit-symbol-map -sMEMORY64=1 CMakeFiles/main.dir/main.o -o main.js   && :
[wasm-validator error in function __original_main] unexpected false: non-final block elements returning a value must be dropped, on 
(block (result i32)
 (call $__pthread_self_internal)
 (i64.const 2)
 (i32.const 0)
)
(on index 0:
0x3b028360310
), type: i64
[wasm-validator error in function __original_main] unexpected false: non-final block elements returning a value must be dropped, on 
(block (result i32)
 (call $__pthread_self_internal)
 (i64.const 2)
 (i32.const 0)
)
(on index 1:
0x3b028360358
), type: i64
Fatal: error validating input
em++: error: '/emsdk/upstream/bin/wasm-opt --print-function-map main.wasm --mvp-features --enable-bulk-memory --enable-bulk-memory-opt --enable-call-indirect-overlong --enable-memory64 --enable-multivalue --enable-mutable-globals --enable-nontrapping-float-to-int --enable-reference-types --enable-sign-ext' failed (returned 1)
ninja: build stopped: subcommand failed.

I did test this on the recent release of Emscripten (4.0.15) and while if did not crash during the compilation, we hit an abort when we tried to load the compiled module on the web with a similar message about value being dropped.

[kripken]

I did test this on the recent release of Emscripten (4.0.15) and while if did not crash during the compilation, we hit an abort when we tried to load the compiled module on the web with a similar message about value being dropped.

That seems odd: That "dropped" message is something very specific in Binaryen, and I'm not aware of any browser that has a similar error message.

Perhaps you are getting a different error in the browser? A screenshot could clarify matters.

[poretga99]

Here is a screenshot of the error log. This was built using the latest release of Emscripten (4.0.15). As stated before, this works just fine in Release mode.

failed to asynchronously prepare wasm: CompileError: wasm validation error: at offset 981517: unused values not explicitly dropped by end of block

Firefox

Chrome

Edit:
The screenshot above is not based on this simple reproducible but is our actual production code, which is way more complex, but I sadly cannot share it. I did manage to replicate the compilation error using the initial example (on 4.0.13).

[poretga99]

After the inspection of the generated App.js.symbols, which were exported via the --emit-symbol-map,
function 305 (chrome log) is the following:

305:emscripten::val emscripten::val::internalCall<(emscripten::internal::EM_INVOKER_KIND)1, emscripten::internal::WithPolicies<>, emscripten::val>(emscripten::_EM_VAL*, char const*)

[kripken]

Ok, interesting, then there must be two issues here, based on the "edit" part of your previous comment. The first, which shows up on the small testcase, was a binaryen issue that has been fixed. The second, which only shows up on your production code, happens in VMs/browsers.

It seems odd the two share such similar dropped errors... that is quite strange!

Anyhow, without a way to reproduce the remaining/second issue, I don't have an idea for how to investigate it. Perhaps you can get a reduced testcase for it?

[poretga99]

Here is a simple reproducible for the latest release (4.0.15)

reproducible.zip

Extract the zip file and execute the following

emcmake cmake . -DCMAKE_BUILD_TYPE=Release && cmake --build . && emrun --port 8080 main.html

Edit:
Just in case, I'm also attaching the prebuilt wasm and js files

Archive.zip

[kripken]

Thanks!

Ok, this looks like an LLVM bug with -Og... this is enough to show the problem:

#include <emscripten/bind.h>

int main() {
    emscripten::val v;
    v.call<void>("print");
}

$ em++.py main.cpp -Og -c -o a.o

Then that object file is invalid (d8 errors on CompileError: WebAssembly.Module(): Compiling function #4 failed: expected 1 elements on the stack for fallthru, found 3 @+289; binaryen errors on non-final block elements returning a value must be dropped).

Other opt levels than -Og work ok (-O1, -O3, and even combinations with -g). So the problem is -Og specifically.

@sbc100 any idea?

[sbc100]

Is this a regression or long standing issue with -Og?

[kripken]

Looks like it regressed in 4.0.11.

I bisected, but unfortunately this hits a range of missing builds - something I've never seen before - so bisection ended up with

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
f302bb62b770b98e3d843c1ee2868735ddd04dca
4fb0ad5ca0740b79923b81323434ffdc98c57ce0
79d2429339c873bc3196d5cee7280aa3a649cdbc
71706a6c1a3647c42018e9a43898f8f2a01511ab
fd8632df5b12976b8ae30794a3e679afdc299766
5b576123cacc2390a812a08b82034e16c736d538
f25cc72259d76188a006b4c9bc3504de5b77c499
8dd3f6214ccea34bc3591763bc0080dec156c572
We cannot bisect more!

Example of a missing build:

$ ./emsdk install 71706a6c1a3647c42018e9a43898f8f2a01511ab
Installing SDK 'sdk-releases-71706a6c1a3647c42018e9a43898f8f2a01511ab-64bit'..
Skipped installing node-22.16.0-64bit, already installed.
Installing tool 'releases-71706a6c1a3647c42018e9a43898f8f2a01511ab-64bit'..
Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/71706a6c1a3647c42018e9a43898f8f2a01511ab/wasm-binaries.tar.xz': HTTP Error 404: Not Found
Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/71706a6c1a3647c42018e9a43898f8f2a01511ab/wasm-binaries.tbz2': HTTP Error 404: Not Found
Error: Downloading URL 'https://storage.googleapis.com/webassembly/emscripten-releases-builds/linux/71706a6c1a3647c42018e9a43898f8f2a01511ab/wasm-binaries.tar.xz': HTTP Error 404: Not Found
error: installation failed!

If those LLVM rolls don't suggest anything specific, I guess the next step would be to bisect LLVM directly.

[kripken]

(4.0.11 changlog mentions one embind change, #24678. I checked it and it is not to blame.)

[kripken]

Bisected to

36af7345dfb8e84a1f2971db34089b63321e8467 is the first bad commit
commit 36af7345dfb8e84a1f2971db34089b63321e8467 (HEAD)
Author: Stephen Tozer <stephen.tozer@sony.com>
Date:   Thu May 15 11:43:49 2025 +0100

    Reapply "[Clang] Enable -fextend-variable-liveness at -Og (#118026)"
    
    Relands this feature after several fixes:
    
    * Force fake uses to be emitted before musttail calls (#136867)
    * Added soften-float legalization for fake uses (#142714)
    * Treat fake uses as size-less instructions in a SystemZ assert (#144390)
    
    If further issues with fake uses are found then this may be reverted again,
    but all currently-known issues are resolved.
    
    This reverts commit 2dc6e98169baeb1f73036da0ea50fd828d8323d0.

 clang/docs/CommandGuide/clang.rst            | 7 +++++--
 clang/docs/ReleaseNotes.rst                  | 4 ++++
 clang/lib/Driver/ToolChains/Clang.cpp        | 8 +++++++-
 clang/test/Driver/extend-variable-liveness.c | 3 ++-
 4 files changed, 18 insertions(+), 4 deletions(-)

[sbc100]

Nice work @kripken. I wonder if its worth commenting on that PR on the llvm side? Maybe somebody there has some idea what is going on here.