Created attachment 8799141 [details] classes.wasm.tar.gz User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Steps to reproduce: Loaded a wasm file that contains the following fragment: (block $@block#5 ;; org/teavm/classlib/java/lang/TInteger.java:112 (br_if $@block#5 ;; org/teavm/classlib/java/lang/TInteger.java:112 (i32.const 0) (i32.lt_s (get_local 0) (i32.const -128))) ;; org/teavm/classlib/java/lang/TInteger.java:112 (i32.le_s (get_local 0) (i32.const 127))) and the corresponding binary (0xC version) sequence: $ hexdump classes.wasm -s 0x30ec -n 19 -C 000030ec 01 01 10 00 14 00 10 80 7f 4f 07 00 14 00 10 ff |.........O......| 000030fc 00 50 0f |.P.| Actual results: FF reports "TypeError: wasm validation error: at offset 12543: unused values not explicitly dropped by end of block" Expected results: Not sure, but cound not found what's wrong with the provided fragment, therefore I expect Firefox should not report error here.
Product: Firefox → Core
Thanks for filing! I think that if the br_if is not taken, the (i32.const 0) remains on the value_stack, so it needs to be explicitly dropped. Adding a `(drop)` opcode around the (br_if) should be enough. Is that correct, Dan?
Yes, br_if should leave its branch value on the stack for both the taken and not-taken branch.
That's correct. Also, the `le_s` is also unused at block exit fallthrough and needs to be explicitly dropped.
Thanks for the confirmation! So this is the code generator's role to generate the drop operands, in this case. Closing as invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
Type of the block is int32 (you can see first two bytes are 1, 1), so the value of le_s is not unused.
Ah, I had looked at the text presentation rather than the bytes. The WebAssembly text format now requires blocks with return values to state them explicitly.
You need to log in before you can comment on or make changes to this bug.