Emscripten: Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!")

[hostilefork]

UPDATE: I'd closed this due to not being able to reproduce it in modern Emscripten, but it seems to be arising for someone else when Link-Time-Optimization is enabled has been found (see below), so I've reopened it.

I apologize for not having a small self-contained repro case for this, but I can't seem to get it to happen when the code is isolated out of its larger context. So I'm hoping that the errors might point to how it might be narrowed down, or whether it's an LLVM bug or what.

I basically have code that looks like this:

 unsigned int addr;
 if (local_eval)
     addr = MAIN_THREAD_EM_ASM_INT(
        { return reb.Box(eval(UTF8ToString($0))) },  // direct call
        utf8
    );
else
    addr = MAIN_THREAD_EM_ASM_INT(
        { return reb.Box((1,eval)(UTF8ToString($0))) },  // indirect call
        utf8
    );
REBVAL *result = (REBVAL*)addr;
return result;

(For what this pertains to, see the article "Global Eval: What are the Options")

At the link step this produces errors (which I have attached at the bottom). However, there are many changes I can make which don't preserve my intent...but do make the errors go away:

1. Comment out the second branch
2. Change the second branch to match the code of the first, so just eval and not (1,eval)
3. Change from MAIN_THREAD_EM_ASM_INT to plain EM_ASM_INT, or just use plain MAIN_THREAD_EM_ASM

(Note on 2: I saw that sometimes there are problems with commas and you have to wrap code in parentheses, but that doesn't seem to help here (also the (1, eval) pattern works elsewhere).)

None of those changes serve my purpose (I just mention them as data points). However it works if I rewrite the code not to share the result variable of the evaluation directly...giving each branch its own unsigned int:

 if (local_eval) {
     unsigned int addr = MAIN_THREAD_EM_ASM_INT(
        { return reb.Box(eval(UTF8ToString($0))) },  // direct call
        utf8
    );
   result = (REBVAL*)addr;
}
else {
    unsigned int addr = MAIN_THREAD_EM_ASM_INT(
        { return reb.Box((1,eval)(UTF8ToString($0))) },  // indirect call
        utf8
    );
    result = (REBVAL*)addr;
}
return result;

So it seems to be a fairly peculiar intersection of circumstances. Taking basically the exact code and sticking it in a standalone int main() doesn't reproduce the problem with an attempt at the same command-line options.

I'm using emcc 1.38.28 on Kubuntu Linux, and the command line options look like:

emcc -shared -o libr3.js -Os -s ENVIRONMENT='web,worker' -s ASSERTIONS=1 --closure 0 --minify 0 --post-js prep/include/reb-lib.js -s DISABLE_EXCEPTION_CATCHING=1 -s DEMANGLE_SUPPORT=0 -s EXPORTED_FUNCTIONS=@prep/include/libr3.exports.json -s "EXTRA_EXPORTED_RUNTIME_METHODS=['allocateUTF8']" -s WASM=1 -s SAFE_HEAP=0 -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=1

The errors from the top example come back looking like:

#0 0x000000000130c4ba llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x130c4ba)
#1 0x000000000130a59e llvm::sys::RunSignalHandlers() (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x130a59e)
#2 0x000000000130a6ec SignalHandler(int) (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x130a6ec)
#3 0x00007fec44509150 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13150)
#4 0x00007fec4379e024 (/lib/x86_64-linux-gnu/libc.so.6+0x17f024)
#5 0x00000000008131a7 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.709] (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x8131a7)
#6 0x0000000000850b60 (anonymous namespace)::JSWriter::handleAsmConst(llvm::Instruction const*, (anonymous namespace)::JSWriter::EmAsmCallType) [clone .constprop.1144] (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x850b60)
#7 0x0000000000851897 (anonymous namespace)::JSWriter::CH_emscripten_asm_const_int_sync_on_main_thread(llvm::Instruction const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int) (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x851897)
#8 0x0000000000853e10 (anonymous namespace)::JSWriter::generateExpression(llvm::User const*, llvm::raw_string_ostream&) [clone .constprop.1159] (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x853e10)
#9 0x0000000000875abf (anonymous namespace)::JSWriter::printFunctionBody(llvm::Function const*) [clone .constprop.1118] (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x875abf)
#10 0x00000000008791a9 (anonymous namespace)::JSWriter::printModuleBody() [clone .constprop.1110] (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x8791a9)
#11 0x000000000087cb99 (anonymous namespace)::JSWriter::runOnModule(llvm::Module&) (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x87cb99)
#12 0x0000000000df7224 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0xdf7224)
#13 0x000000000060a0f7 compileModule(char**, llvm::LLVMContext&) [clone .constprop.394] (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x60a0f7)
#14 0x00000000005c2d3d main (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x5c2d3d)
#15 0x00007fec436401c1 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x211c1)
#16 0x00000000005fee79 _start (/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc+0x5fee79)
Stack dump:
0.      Program arguments: /home/hostilefork/emsdk/clang/e1.38.28_64bit/llc /tmp/emscripten_temp_3OLAkN/libr3.bc -march=js -filetype=asm -o /tmp/tmpZRAqgX.4.js -emscripten-stack-size=5242880 -O2 -emscripten-precise-f32 -emscripten-enable-pthreads -emscripten-assertions=1 -emscripten-global-base=1024 -emscripten-no-exit-runtime -emscripten-wasm -emscripten-only-wasm 
1.      Running pass 'JavaScript backend' on module '/tmp/emscripten_temp_3OLAkN/libr3.bc'.
Traceback (most recent call last):
  File "/home/hostilefork/emsdk/emscripten/1.38.28/emcc.py", line 3220, in <module>
    sys.exit(run(sys.argv))
  File "/home/hostilefork/emsdk/emscripten/1.38.28/emcc.py", line 1882, in run
    final = shared.Building.emscripten(final, target + '.mem', js_libraries)
  File "/home/hostilefork/emsdk/emscripten/1.38.28/tools/shared.py", line 2315, in emscripten
    emscripten.run(infile, outfile, memfile, js_libraries)
  File "/home/hostilefork/emsdk/emscripten/1.38.28/emscripten.py", line 2499, in run
    return temp_files.run_and_clean(lambda: emscripter(
  File "/home/hostilefork/emsdk/emscripten/1.38.28/tools/tempfiles.py", line 105, in run_and_clean
    return func()
  File "/home/hostilefork/emsdk/emscripten/1.38.28/emscripten.py", line 2500, in <lambda>
    infile, outfile_obj, memfile, libraries, shared.COMPILER_ENGINE, temp_files, shared.DEBUG)
  File "/home/hostilefork/emsdk/emscripten/1.38.28/emscripten.py", line 89, in emscript
    backend_output = compile_js(infile, temp_files, DEBUG)
  File "/home/hostilefork/emsdk/emscripten/1.38.28/emscripten.py", line 118, in compile_js
    jsrun.timeout_run(subprocess.Popen(backend_args, stdout=subprocess.PIPE, universal_newlines=True), note_args=backend_args)
  File "/home/hostilefork/emsdk/emscripten/1.38.28/tools/jsrun.py", line 27, in timeout_run
    raise Exception('Subprocess "' + ' '.join(note_args) + '" failed with exit code ' + str(proc.returncode) + '!')
Exception: Subprocess "/home/hostilefork/emsdk/clang/e1.38.28_64bit/llc /tmp/emscripten_temp_3OLAkN/libr3.bc -march=js -filetype=asm -o /tmp/tmpZRAqgX.4.js -emscripten-stack-size=5242880 -O2 -emscripten-precise-f32 -emscripten-enable-pthreads -emscripten-assertions=1 -emscripten-global-base=1024 -emscripten-no-exit-runtime -emscripten-wasm -emscripten-only-wasm" failed with exit code -11!
makefile:223: recipe for target 'libr3.js' failed

[hostilefork]

While my rewrite seemed to work on the Linux clang I had on hand, a Mac on Travis-CI building the same source wasn't appeased. That compiler build gives an actual "Assertion Failed" message:

Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /b/s/w/ir/cache/builder/emscripten-releases/emscripten-fastcomp/include/llvm/Support/Casting.h, line 255.
0  libLLVM.dylib            0x0000000106bb4905 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  libLLVM.dylib            0x0000000106bb4f66 SignalHandler(int) + 486
2  libsystem_platform.dylib 0x00007fff730a8f5a _sigtramp + 26
3  libsystem_platform.dylib 0x0000000000000001 _sigtramp + 2364895425
4  libsystem_c.dylib        0x00007fff72e461ae abort + 127
5  libsystem_c.dylib        0x00007fff72e0e1ac basename_r + 0
6  libLLVM.dylib            0x00000001081cd262 (anonymous namespace)::JSWriter::handleAsmConst(llvm::Instruction const*, (anonymous namespace)::JSWriter::EmAsmCallType) + 3714
7  libLLVM.dylib            0x0000000108194a8a (anonymous namespace)::JSWriter::CH_emscripten_asm_const_int_sync_on_main_thread(llvm::Instruction const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int) + 282
8  libLLVM.dylib            0x00000001081aee38 (anonymous namespace)::JSWriter::generateExpression(llvm::User const*, llvm::raw_string_ostream&) + 16024
9  libLLVM.dylib            0x00000001081dcf0a (anonymous namespace)::JSWriter::printFunctionBody(llvm::Function const*) + 522
10 libLLVM.dylib            0x00000001081d04c8 (anonymous namespace)::JSWriter::printModuleBody() + 10232
11 libLLVM.dylib            0x000000010815d296 (anonymous namespace)::JSWriter::runOnModule(llvm::Module&) + 1590
12 libLLVM.dylib            0x0000000106ce12f8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 968
13 llc                      0x00000001067f2638 compileModule(char**, llvm::LLVMContext&) + 10888
14 llc                      0x00000001067ef97b main + 1275
15 libdyld.dylib            0x00007fff72d9a015 start + 1
16 libdyld.dylib            0x000000000000000f start + 2368102395

Since I had luck with a minor rewrite in the other build getting past it, I decided to try another one...and it seemed to get past it there... dropping the else clause and making two separate return points:

if (local_eval) {
    unsigned int addr = MAIN_THREAD_EM_ASM_INT(
        { return reb.Box(eval(UTF8ToString($0))) },  // direct call
        utf8
    );
    return (REBVAL*)addr;
}

unsigned int addr = MAIN_THREAD_EM_ASM_INT(
    { return reb.Box((1,eval)(UTF8ToString($0))) },  // indirect call
    utf8
);
return (REBVAL*)addr;

The specs on that virtual container are:

Configured with: --prefix=/Applications/Xcode-10.1.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode-10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Though now that I'm reading up on Fastcomp, that may not be interesting to you if emcc installs a different clang. In any case, it's running the latest emsdk installed via git clone.

[hostilefork]

Changed the code back to how I wanted to write it initially, and it seems that in the post-Fastcomp era with the new clang version, the error doesn't happen.

So closing it! _{Though I lament that we as a culture live in an era where we are driven to move so fast on things that we never know quite what we are doing, or why things were broken before but magically fixed. Obligatory xkcd.}

[DoDoENT]

I've just got the exact same assertion failure using emscripten 1.39.11 with upstream backend when LTO is enabled.

[build] Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/include/llvm/Support/Casting.h, line 263.

0  libLLVM.dylib            0x000000010a7ed5a5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  libLLVM.dylib            0x000000010a7ec3a8 llvm::sys::RunSignalHandlers() + 248
2  libLLVM.dylib            0x000000010a7edb96 SignalHandler(int) + 262
3  libsystem_platform.dylib 0x00007fff706a05fd _sigtramp + 29
4  libLLVM.dylib            0x000000010cee1180 (anonymous namespace)::NoOpLoopAnalysis::Key + 113576
5  libsystem_c.dylib        0x00007fff70576808 abort + 120
6  libsystem_c.dylib        0x00007fff70575ac6 err + 0
7  libLLVM.dylib            0x000000010bda5cd3 (anonymous namespace)::WasmObjectWriter::recordRelocation(llvm::MCAssembler&, llvm::MCAsmLayout const&, llvm::MCFragment const*, llvm::MCFixup const&, llvm::MCValue, unsigned long long&) + 2483
8  libLLVM.dylib            0x000000010bd567dd llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&, llvm::MCFixup const&) + 637
9  libLLVM.dylib            0x000000010bd56d78 llvm::MCAssembler::layout(llvm::MCAsmLayout&) + 1304
10 libLLVM.dylib            0x000000010bd5757e llvm::MCAssembler::Finish() + 46
11 libLLVM.dylib            0x000000010b0ca564 llvm::AsmPrinter::doFinalization(llvm::Module&) + 6868
12 libLLVM.dylib            0x000000010a94e006 llvm::FPPassManager::doFinalization(llvm::Module&) + 54
13 libLLVM.dylib            0x000000010a94e576 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1334
14 libLLVM.dylib            0x000000010bd243ba (anonymous namespace)::codegen(llvm::lto::Config const&, llvm::TargetMachine*, std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_delete<llvm::lto::NativeObjectStream> > (unsigned int)>, unsigned int, llvm::Module&) + 1530
15 libLLVM.dylib            0x000000010bd21a8c llvm::lto::backend(llvm::lto::Config const&, std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_delete<llvm::lto::NativeObjectStream> > (unsigned int)>, unsigned int, std::__1::unique_ptr<llvm::Module, std::__1::default_delete<llvm::Module> >, llvm::ModuleSummaryIndex&) + 396
16 libLLVM.dylib            0x000000010bd1982d llvm::lto::LTO::runRegularLTO(std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_delete<llvm::lto::NativeObjectStream> > (unsigned int)>) + 2173
17 libLLVM.dylib            0x000000010bd18b45 llvm::lto::LTO::run(std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_delete<llvm::lto::NativeObjectStream> > (unsigned int)>, std::__1::function<std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_delete<llvm::lto::NativeObjectStream> > (unsigned int)> (unsigned int, llvm::StringRef)>) + 949
18 wasm-ld                  0x0000000108c57949 lld::wasm::BitcodeCompiler::compile() + 777
19 wasm-ld                  0x0000000108c5b6aa lld::wasm::SymbolTable::addCombinedLTOObject() + 170
20 wasm-ld                  0x0000000108c4644b lld::wasm::(anonymous namespace)::LinkerDriver::link(llvm::ArrayRef<char const*>) + 20651
21 wasm-ld                  0x0000000108c410f8 lld::wasm::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) + 312
22 wasm-ld                  0x0000000108991f0e main + 1070
23 libdyld.dylib            0x00007fff704a7cc9 start + 1
24 libdyld.dylib            0x000000000000005f start + 18446603338632233879

However, when I switch to fastcomp, it works.

[DoDoENT]

Disabling LTO also works (but neither fastcomp nor disabling LTO is good for what I need).

[DoDoENT]

Also happens with emscripten 1.39.13 upstream.

[hostilefork]

Given that it's still around in modern Emscripten, I reopened it. I had trouble narrowing it down to a smaller case than I had. Maybe you can have better luck if there's any way you can narrow it down.

[sbc100]

Do either you have a repo case for this? The the OP's example code cause this issue? Could you attach a complete program, or bincode object files, can that trigger this?

[DoDoENT]

Unfortunately no (it's a closed source program). But I can tell you this:

• replacing code like this:

// header
class SomeClass {
  public:
    SomeClass();
    virtual ~SomeClass();
}
// source
 SomeClass::SomeClass() {
 }
 SomeClass::~SomeClass() {
 }

with

class SomeClass {
  public:
    // Constructor / Destructor
    SomeClass() = default;
    virtual ~SomeClass() = default;
}

and completely removing the source removed the crash.

Also, other sources have a similar pattern (it's a legacy codebase), but the same trick didn't work. However, adding -fno-lto only on specific two source files with that code pattern did the trick. The mystery is why other source files with the same pattern are OK with having LTO enabled?

Also, one of those two files has a pattern with lots of getters and setters declared in the header and implemented in source. If I move all those implementations to the header and completely remove the source file from the compilation, I get this assert. But, as soon as I restore implementations of those getters and setters back to the source file (and keep only declarations in the header) and add -fno-lto on it, then it no longer crashes.

I wish I could share that code with you (it's a legacy system, however it's still closed source) to ease your debugging, but unfortunately, I can't.

I'd guess different inlining choices in the LTO determine whether this assert happens or not. I assumed this based on the behaviour of getters/setters I described above (if those get implemented in the header, then I would probably need to add -fno-lto to some other file that uses them.

I hope this gives some better insight into the issue.

[DoDoENT]

Good news 🎉 !

I have managed to reproduce the LTO assert on slightly modified open source project. Check out this repository: https://github.com/dodoent/jtorch

[DoDoENT]

Also this commit removes the LTO crash (it's what I described earlier).

[DoDoENT]

Also, I am using emscripten 1.39.13 on macOS. I didn't try if the above case can be reproduced on Windows or Linux.

[sbc100]

Sounds like its relates to vtables.

I'd love to be able to repro. Do you have repro steps for building https://github.com/dodoent/jtorch?

[DoDoENT]

Do you have repro steps for building https://github.com/dodoent/jtorch?

Yes, those are written in README file in the repository. I'll copy them here, for convenience:

1. Install emscripten 1.39.11 or 1.39.13 with upstream backend
2. use its cmake toolchain to configure the project in release mode
3. build it

Or as a bash script 😎

git clone https://github.com/dodoent/jtorch
pushd jtorch
git submodule update --init
popd
mkdir build
cd build
emcmake cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../jtorch
ninja

[sbc100]

Sorry, I didn't mean to ask an obvious questions, I just wanted to know that exact steps, e.g. the build configuration used before trying to reproduce without certainty. Its great to provide clear steps like this in the actual bug, I appreciate it!

[DoDoENT]

Have you had any success in reproducing this on your side? We are running into this issue in our codebase and this currently prevents us from moving to the upstream backend.

[sbc100]

I was able to reproduce but its such a large prepro case I've not had time to pick it apart to find the root cause.

As a temporary workoround can you disable LTO in your build? Our results for LTO have been mixed at best, are you sure LTO is helping you with the webassembly build? In particular we are seeing binaries get larger (fairly consistently) with LTO which matter more on the web than other platforms.

[DoDoENT]

Until this gets fixed, we will stick with using fastcomp as our backend. Our codebase heavily depends on cross-compilation-unit inlining, which is only available when LTO is enabled. Additionally, LTO produces the smallest possible binary for our codebase accross all platforms we support.

[sbc100]

The llvm side fix is here: https://reviews.llvm.org/D79462.

Will update here when it lands and when it rolls into an emscripten release.

[DoDoENT]

I've tried with emscripten 2.0.8 and now I get different error (using the same project as above):

FAILED: TorchTest.js 
: && /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/em++ -DNDEBUG -O2 -O2   --llvm-lto 3 --llvm-opts 3 -s STRICT=1 -s ALLOW_MEMORY_GROWTH=1 --no-heap-copy -s INITIAL_MEMORY=209715200 CMakeFiles/TorchTest.dir/TorchTest.cpp.o -o TorchTest.js  libTorchLib.a  libBlasLibrary.a && :
emcc:WARNING: --llvm-lto ignored when using llvm backend
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=72 expected=1848
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=72 expected=1848
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=104 expected=2068
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=296 expected=2260
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=40 expected=2004
wasm-ld: error: unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=200 expected=2164
wasm-ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
em++: error: '/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/bin/wasm-ld -o /var/folders/w1/67dfjvfs6sd66rd33brg4d5r0000gn/T/emscripten_temp_pj0fger2/TorchTest.wasm CMakeFiles/TorchTest.dir/TorchTest.cpp.o -L/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/local/lib libTorchLib.a -L/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/lib libBlasLibrary.a -L/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libc.a /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libcompiler_rt.a /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libc++-noexcept.a /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libc++abi-noexcept.a /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libdlmalloc.a /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libpthread_stub.a /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libc_rt_wasm.a /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm/libsockets.a --fatal-warnings -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --allow-undefined --import-memory --strip-debug --export-table --export main --export stackSave --export stackRestore --export stackAlloc --export __data_end --export __wasm_call_ctors --export __errno_location --export malloc --export free --export setThrew -z stack-size=5242880 --initial-memory=209715200 --entry=main --max-memory=2147483648 --global-base=1024' failed (1)
ninja: build stopped: subcommand failed.

[sbc100]

Do those error still occur if you rebuild all your object and libraries (e.g. libTorchLib.a libBlasLibrary.a and all the objects inside of them?)

[DoDoENT]

Yes, I just did a clean build.

[DoDoENT]

Try reproducing that on your side by following steps as in my previous comment, but using 2.0.8.

[sbc100]

I tried following your instructions but got:

../TorchTest.cpp:3:10: fatal error: 'Paths.h' file not found
#include "Paths.h"

[sbc100]

If you build without STRICT=1 these should becoming just warnings.. can you see if the resulting program works?

[sbc100]

I'm uploaded an llvm change to make these error more informative: https://reviews.llvm.org/D90443

[DoDoENT]

As suggested, building without STRICT=1 makes the program compile and this sample works.

However, in order to be able to test that on my real codebase, issue #12639 needs to be fixed first.

Thank you for addressing this issue.

[DoDoENT]

However, in the long-term, it is beneficial to compile code with STRICT=1, as it prevents accidental usage of deprecated stuff.

[sbc100]

Oh course.. I want to encourage as many people as possible to use STRICT=1 .. normally we would have sub-option for each thing that strict enables so you can turn individual ones one and off, but in this case we don't (yet).

BTW, my llvm change landed so pretty soon you can install tot and get a more informative error message.

[DoDoENT]

BTW, my llvm change landed so pretty soon you can install tot and get a more informative error message.

Sorry for asking a n00b question, but what is tot and how to install it 😇 ?

[sbc100]

./emsdk update-tags && ./emsdk isntall tot (tot is an alternative to latest that includes changes that are not yet officially released).

[DoDoENT]

I've tried building the same project with tot and the linker warning (error in strict mode) is the following:

wasm-ld: warning: lto.tmp:(_ZN12TorchLibTest15testmtorchValueEPN6mtorch6TensorIfEERKNSt3__212basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEEf): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=72 expected=1848
wasm-ld: warning: lto.tmp:(_ZN12TorchLibTest15testmtorchValueEPN6mtorch6TensorIfEERKNSt3__212basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEEf): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN12TorchLibTest15testmtorchValueEPN6mtorch6TensorIfEERKNSt3__212basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEEf): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZNSt3__213basic_filebufIcNS_11char_traitsIcEEED2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=72 expected=1848
wasm-ld: warning: lto.tmp:(_ZNSt3__218basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEC1Ej): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZNSt3__215basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEED2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZNSt3__215basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEED0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZNSt3__218basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZNSt3__218basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZThn8_NSt3__218basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZThn8_NSt3__218basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZTv0_n12_NSt3__218basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZTv0_n12_NSt3__218basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1784
wasm-ld: warning: lto.tmp:(_ZN6mtorch6TensorIfED2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch6TensorIfED0Ev$merged): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=104 expected=2068
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=296 expected=2260
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=40 expected=2004
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=200 expected=2164
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=200 expected=2164
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=264 expected=2228
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=104 expected=2068
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=72 expected=2036
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1972
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(__original_main): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=104 expected=2068
wasm-ld: warning: lto.tmp:(_ZN6mtorch6TensorIfE5cloneERS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch17SpatialMaxPooling11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch6LinearD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1972
wasm-ld: warning: lto.tmp:(_ZN6mtorch6LinearD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch6LinearD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch6LinearD0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=8 expected=1972
wasm-ld: warning: lto.tmp:(_ZN6mtorch6LinearD0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch6LinearD0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch6Linear11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch6Linear11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_LEB: existing=0 expected=1904
wasm-ld: warning: lto.tmp:(_ZN6mtorch9Threshold11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch9Threshold11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_LEB: existing=0 expected=1904
wasm-ld: warning: lto.tmp:(_ZN6mtorch7ReshapeD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=72 expected=2036
wasm-ld: warning: lto.tmp:(_ZN6mtorch7ReshapeD0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=72 expected=2036
wasm-ld: warning: lto.tmp:(_ZN6mtorch7Reshape11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch10SequentialD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=104 expected=2068
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemmD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=200 expected=2164
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemmD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemmD2Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemmD0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=200 expected=2164
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemmD0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemmD0Ev): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemm11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemm11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemm11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemm11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch22SpatialConvolutionGemm11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch4Tanh11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_SLEB: existing=12 expected=1916
wasm-ld: warning: lto.tmp:(_ZN6mtorch4Tanh11forwardPropERNS_9TorchDataEPPS1_): unexpected existing value for R_WASM_MEMORY_ADDR_LEB: existing=0 expected=1904

Hopefully it' helpful...

[sbc100]

Oh crap.. are those all errors that didn't exist before but just started happening?

Are the LTO only? (i.e. if you build without LTO do they go away?)

[DoDoENT]

If I remove LTO, the errors are gone.

I can't tell if that just started happening because I am still using fastcomp in production (I couldn't use upstream because of the assert which started this issue anyway).

On fastcomp LTO works without these errors.