[llvm-bugs] [Bug 37401] New: wasm32: Runtime signature for __muloti4 may be wrong

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37401

            Bug ID: 37401
           Summary: wasm32: Runtime signature for __muloti4 may be wrong
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: dan433584 at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 20279
  --> https://bugs.llvm.org/attachment.cgi?id=20279&action=edit
IR

When Rust code uses LLD and turns on `--fatal-warnings` with LLD recent builds
of LLD will fail with:


lld: error: Function type mismatch: __muloti4
>>> defined as (I32, I64, I64, I64, I64) -> void in core-e5bf43c84917cf15.core5-ceca1e00e36ddf6282e22e0bc4528df.rs.rcgu.o
>>> defined as (I32, I64, I64, I64, I64, I32) -> void in compiler_builtins-9dbaa47e4e7765c7.compiler_builtins4-c780f72fce4e9840f0ab093af18d8809.rs.rcgu.o


Our __muloti4 implementation [1] is located in compiler_builtins (the second of
those two object files) and the last extra argument is the flag as to whether
the call overflowed. It looks like, though, that the wasm code generator isn't
expecting that flag to be there, which seems odd?

If the attached IR is compiled and disassembled with `wasm2wat` you can see
that LLVM is emitting the first signature above (no flag at the end). The
internal IR (I think?) looks to have a final trailing argument but it seems to
be chopped off somewhere in the wasm backend.

Is this signature different on wasm? Or is this a bug in the wasm codegen?

[1]:
https://github.com/rust-lang-nursery/compiler-builtins/blob/cb04a0718b2437a32436d4cc2eb66d012066c835/src/int/mul.rs#L105-L108

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180509/ebba2a10/attachment.html>