[llvm-bugs] [Bug 44381] New: wasm-validate: type mismatch in function, expected [] but got [i32]

[via llvm-bugs]

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

            Bug ID: 44381
           Summary: wasm-validate: type mismatch in function, expected []
                    but got [i32]
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: wasm
          Assignee: unassignedbugs at nondot.org
          Reporter: scott.waye at hubse.com
                CC: llvm-bugs at lists.llvm.org, sbc at chromium.org

I'm getting this error from wasm-validate, after wasm-ld.  Running

E:/GitHub/emsdk/upstream/bin\wasm-ld.exe -o
c:\users\scottw~1\appdata\local\temp\emscripten_temp\HelloWasm.wasm
--allow-undefined --lto-O0
E:\GitHub\corert\tests\src\Simple\HelloWasm\obj\Debug\wasm\native\HelloWasm.bc
E:\GitHub\corert\tests\\..\bin\WebAssembly.wasm.Debug/sdk/libPortableRuntime.a
E:\GitHub\corert\tests\\..\bin\WebAssembly.wasm.Debug/sdk/libbootstrappercpp.a
E:\GitHub\corert\tests\\..\bin\WebAssembly.wasm.Debug/sdk/libSystem.Private.CoreLib.Native.a
-LE:\GitHub\emsdk\upstream\emscripten\system\local\lib
-LE:\GitHub\emsdk\upstream\emscripten\system\lib
-LC:\Users\ScottWaye\.emscripten_cache\wasm-obj
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libc.a
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libcompiler_rt.a
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libc-wasm.a
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libc++-noexcept.a
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libc++abi-noexcept.a
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libdlmalloc-debug.a
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libpthread_stub.a
C:\Users\ScottWaye\.emscripten_cache\wasm-obj\libc_rt_wasm.a --import-memory
--import-table -mllvm -combiner-global-alias-analysis=false -mllvm
-enable-emscripten-sjlj -mllvm -disable-lsr --export __wasm_call_ctors --export
__data_end --export main --export malloc --export free --export setThrew
--export __errno_location --export fflush --export emscripten_builtin_memalign
--export memalign --export emscripten_builtin_free --export
_ZSt18uncaught_exceptionv --export _get_environ -z stack-size=5242880
--initial-memory=16777216 --no-entry --global-base=1024

Where the input files are at
https://hubsoftwareengineering-my.sharepoint.com/:u:/g/personal/scott_waye_hubse_com/EXx2lfO3PppIr-d5LevShOgBHVY_k944rFkN1TCnRMJJ7Q?e=Lh9dVl
(too big for here).

wasm-ld is version LLD 10.0.0
(Cswircachegitchromium.googlesource.com-external-github.com-llvm-llvm--project
b5f295ffcec2fa7402e39eb1262acbd55a7d39f5)

This produces a wasm, which can passed to wasm-validate with the output:

c:/users/scottw~1/appdata/local/temp/emscripten_temp/HelloWasm.wasm:01b75a7:
error: type mismatch in function, expected [] but got [i32]

wasm-dis does not complain and produces an output ok.

If I run wasm-validate --verbose, then the message appears between these
functions:

      OnFunctionName(index: 26584, name:
"Internal_CompilerGenerated__Module___InvokeRetVIII<Double__Int32__Int32>")
 c:/users/scottw~1/appdata/local/temp/emscripten_temp/HelloWasm.wasm:01b75a7:
error: type mismatch in function, expected [] but got [i32]
     OnFunctionName(index: 26585, name:
"Internal_CompilerGenerated__Module___InvokeRetVIIII<S_P_CoreLib_System_Action_1<Object>__Object__Int16__Int32>")

Not sure if it refers to the function before, after, or neither.

I'm using emscripten and when I run the build from emscripten, the error is
different

[wasm-validator error in function
$S_P_CoreLib_System_Runtime_RuntimeImports__memset] unexpected true: if block
is not returning a value, final element should not flow out a value, on

This function does end in a local.get which I'm not sure is right as the LLVM
is void:

define void @S_P_CoreLib_System_Runtime_RuntimeImports__memset(i8*, i8*, i32,
i32) {
Prolog:
  %Argument0_ = getelementptr i8, i8* %0, i32 0
  %CastPtr = bitcast i8* %Argument0_ to i8**
  store i8* %1, i8** %CastPtr
  %Argument1_ = getelementptr i8, i8* %0, i32 4
  %CastPtr1 = bitcast i8* %Argument1_ to i32*
  store i32 %2, i32* %CastPtr1
  %Argument2_ = getelementptr i8, i8* %0, i32 8
  %CastPtr2 = bitcast i8* %Argument2_ to i32*
  store i32 %3, i32* %CastPtr2
  br label %Block0

Block0:                                           ; preds = %Prolog
  %Argument0_3 = getelementptr i8, i8* %0, i32 0
  %Argument1_4 = getelementptr i8, i8* %0, i32 4
  %Argument2_5 = getelementptr i8, i8* %0, i32 8
  %CastPtr6 = bitcast i8* %Argument0_3 to i8**
  %Loadarg0_ = load i8*, i8** %CastPtr6
  %CastPtr7 = bitcast i8* %Argument1_4 to i32*
  %Loadarg1_ = load i32, i32* %CastPtr7
  %CastPtr8 = bitcast i8* %Argument2_5 to i32*
  %Loadarg2_ = load i32, i32* %CastPtr8
  %shadowStackTop = getelementptr i8, i8* %0, i32 12
  store i8* %shadowStackTop, i8** @t_pShadowStackTop
  %PInvokeTransitionFrame = alloca { i8*, i8*, i8* }
  call void @RhpPInvoke2({ i8*, i8*, i8* }* %PInvokeTransitionFrame)
  call void @memset(i8* %Loadarg0_, i32 %Loadarg1_, i32 %Loadarg2_)
  call void @RhpPInvokeReturn2({ i8*, i8*, i8* }* %PInvokeTransitionFrame)
  call void @"S_P_CoreLib_System_Runtime_RuntimeImports__memset$FinallyD"(i8*
%0)
  br label %BlockE

BlockE:                                           ; preds = %Block0
  ret void
}

The value pushed to the stack, $5, is the result (if I read the wasm
correctly), of the memset call.  The LLVM for that call is 

call void @memset(i8* %Loadarg0_, i32 %Loadarg1_, i32 %Loadarg2_)

so there is no return, I have memset externed (in c#):

        internal static extern unsafe void memset(byte* mem, int value, nuint
size);

And this does differ from the c++ definition where it is void*.  I changed this
extern to byte* and that does clear the error.  So not sure if there's really a
problem here or not.  The wasm does push a value to the stack when the LLVM
does not, but then again there is a mismatch in memset definitions.

Feel free to close if you think its fine.

-- 
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/20191226/a1ee6389/attachment-0001.html>