[llvm-bugs] [Bug 44012] New: [WebAssembly] Float cast after !! can be wrong when compiled with -x c++

[via llvm-bugs]

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

            Bug ID: 44012
           Summary: [WebAssembly] Float cast after !! can be wrong when
                    compiled with -x c++
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: other
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Backend: WebAssembly
          Assignee: tlively at google.com
          Reporter: bernhard_mlist at outlook.com
                CC: llvm-bugs at lists.llvm.org

With all llvm/clang versions that support the wasm32 target (8, 9, current
build of 10) the following function returns the correct 0.0f when compiled with
'-x c' but it wrongfully returns 1.0f when compiled with '-x c++'.

    #ifdef __cplusplus
    extern "C"
    #endif
    float test()
    {
        static unsigned int mask = 2;
        mask |= 4;
        return (float)(!!(mask & 1));
    }

Here is how I built it to a wasm module:
    clang -x c -nostdinc -O3 -target wasm32 -c -o test.c.o test.c
    wasm-ld -no-entry -export=test -o test.c.wasm test.c.o

    clang -x c++ -nostdinc -O3 -target wasm32 -c -o test.cpp.o test.c
    wasm-ld -no-entry -export=test -o test.cpp.wasm test.cpp.o

And here is how I run the test in node.js v12
    node -e "WebAssembly.instantiate(new
Uint8Array(require('fs').readFileSync('test.c.wasm'))).then(m => {
console.log('c: ' + m.instance.exports.test()); })"
    node -e "WebAssembly.instantiate(new
Uint8Array(require('fs').readFileSync('test.cpp.wasm'))).then(m => {
console.log('cpp: ' + m.instance.exports.test()); })"

The output I get is
    c: 0
    cpp: 1

And this is the disassembly when running it through the wasm2wat tool from
wabt:
    wasm2wat -f test.c.wasm
      (func $test (type 0) (result f32)
        (local i32)
        (i32.store offset=1024
          (i32.const 0)
          (i32.and
            (local.tee 0
              (i32.load offset=1024
                (i32.const 0)))
            (i32.const 5)))
        (f32.convert_i32_s
          (i32.and
            (local.get 0)
            (i32.const 1))))

    wasm2wat -f test.cpp.wasm
      (func $test (type 0) (result f32)
        (local i32)
        (i32.store offset=1024
          (i32.const 0)
          (i32.and
            (local.tee 0
              (i32.load offset=1024
                (i32.const 0)))
            (i32.const 5)))
        (select
          (f32.const 0x1p+0 (;=1;))
          (f32.const 0x0p+0 (;=0;))
          (local.get 0)))

The disassembly of the '-x c' module reads basically what the original C code
was.
But it looks like the '-x c++' module returns something like
(value_of_mask_at_function_entry ? 1 : 0) which makes no sense to me.
If the code line `mask |= 4` is changed into `mask &= 1`, the function returns
1 the first time it is called, then 0 afterwards which matches that assumption
(the '-x c' variant stays correct).

Playing with compilation flag variations like -O0 did not affect the result.

Here's the versions I tested with (all on Win64)
  LLD 10.0.0 / clang version 10.0.0 (trunk) Target: x86_64-pc-windows-msvc 
  LLD 8.0.0 / clang version 8.0.0 (tags/RELEASE_800/final) Target:
x86_64-pc-windows-msvc
  LLD 9.0.0 / clang version 9.0.0 (tags/RELEASE_900/final) Target:
x86_64-pc-windows-msvc

They all produced identical assembly as far as I can tell.

-- 
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/20191115/7437bff4/attachment-0001.html>