cmpxchg atomic will confuse emscripten (was: Error during linking)

[lcoderre]

Hi,

I am currently trying to emscripten-ize one of my projects. I had to tweak a few things, mostly casting, in order to pass the compilation phase.

Now, the error pops during Linking, which I have come to understand is the emscripten compilation phase.

Warning: Casting a function pointer type to a potentially incompatible one (use -s VERBOSE=1 to see more)
Warning: See https://github.com/kripken/emscripten/wiki/CodeGuidlinesAndLimitations#function-pointer-issues for more information on dangerous function
 pointer casts
Stack: Error
    at assertTrue (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:59:26)
    at eval (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:902:15)
    at Array.forEach (native)
    at eval (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:308:23)
    at Array.forEach (native)
    at Object.substrate.addActor.processItem (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:303:24)
    at Object.Actor.process (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:248:26)
    at Object.Substrate.solve (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:184:25)
    at analyzer (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:1742:20)
    at JSify (eval at globalEval (C:\Users\t_codel\work\emscripten\src\compiler.js:105:8), <anonymous>:132:13)

undefined:60
    throw msg;
          ^
Assertion failed: Could not legalize illegal line: 125811,// {
//   "tokens": null,
//   "indent": 2,
//   "lineNum": 125811,
//   "assignTo": "$146",
//   "intertype": "atomic",
//   "op": "cmpxchg",
//   "params": [
//     {
//       "intertype": "value",
//       "ident": "$143",
//       "type": "i64*"
//     },
//     {
//       "intertype": "value",
//       "ident": "$144",
//       "type": "i64"
//     },
//     {
//       "intertype": "value",
//       "ident": "$145",
//       "type": "i64"
//     }
//   ],
//   "type": "i64"
// }
Traceback (most recent call last):
  File "C:\Users\t_codel\work\emscripten\emscripten.py", line 832, in <module>
    _main(environ=os.environ)
  File "C:\Users\t_codel\work\emscripten\emscripten.py", line 820, in _main
    temp_files.run_and_clean(lambda: main(
  File "C:\Users\t_codel\work\emscripten\tools\tempfiles.py", line 38, in run_and_clean
    return func()
  File "C:\Users\t_codel\work\emscripten\emscripten.py", line 828, in <lambda>
    DEBUG_CACHE=DEBUG_CACHE,
  File "C:\Users\t_codel\work\emscripten\emscripten.py", line 714, in main
    jcache=jcache, temp_files=temp_files, DEBUG=DEBUG, DEBUG_CACHE=DEBUG_CACHE)
  File "C:\Users\t_codel\work\emscripten\emscripten.py", line 284, in emscript
    assert len(output) == 2, 'Did not receive forwarded data in an output - process failed? We only got: ' + output[0][-3000:]
AssertionError: Did not receive forwarded data in an output - process failed? We only got: // WARNING: content after a branch in a label, line: 917


Traceback (most recent call last):
  File "C:/Users/t_codel/work/emscripten/emcc", line 1551, in <module>
    final = shared.Building.emscripten(final, append_ext=False, extra_args=extra_args)
  File "C:\Users\t_codel\work\emscripten\tools\shared.py", line 1214, in emscripten
    assert os.path.exists(filename + '.o.js') and len(open(filename + '.o.js', 'r').read()) > 0, 'Emscripten failed to generate .js: ' + str(compiler_
output)
AssertionError: Emscripten failed to generate .js:

Reproduction:
Please note that in 1.5.5 the "Stack: Error" part is not there. This is new from 1.5.6.
(1.5.5 version here http://pastebin.com/n35wNJFe )

And here are the documents required to repro:
https://www.dropbox.com/s/ta9ywd2uyj0u5a5/em.zip

And here is the command used:

python C:/Users/t_codel/work/emscripten/emcc C:/em/AlembicViewer.bc -O2 --js-library C:/em/BrowserView.js --js-library C:/em/ESTextureLoader.js --js-library C:/em/webgl-utils.js --js-library C:/em/HTTPClient.js -s EXPORTED_FUNCTIONS="['_Emscripten_AlembicViewer_LoadFile','_Emscripten_Start','_Emscripten_Tick','_Emscripten_KeyDown','_Emscripten_KeyUp','_Emscripten_MouseDown','_Emscripten_MouseUp','_Emscripten_MouseMove','_Emscripten_MouseWheel','_Emscripten_CreateGLTexture','_Emscripten_DecodedImageDataCB','_Emscripten_DecodeImageFailureCB','_Emscripten_HTTPClient_DownloadFailure','_Emscripten_HTTPClient_DownloadFinished','_Emscripten_HTTPClient_HeadersReceived',]" -s TOTAL_STACK=15000000 -s ALLOW_MEMORY_GROWTH=1 -s ASM_JS=0 -o Staging.js

Clear your cache, and change the paths, then it should repro.

Thanks, Laurens.

[juj]

I can reproduce. Browsing through the code in anlayzer.js, looks like the intertype of 'atomic' is not handled, which is the cause of this issue. Does your source use an atomic intrinsic for compare-and-exchange? (compare_exchange) Can you build your code to not refer to atomics?

[lcoderre]

You spotted it.

We had __sync_bool_compare_and_swap in there. We used a workaround, and now it's all built and working.

Thank you.

I will edit the question and paste the error log instead of pastebin. Perhaps Google will help find this answer for other people with the same problem.

[juj]

Let me reopen this bug, and keep it as a record that this atomic operation will confuse emscripten. Perhaps in the future emscripten itself can implement 'no-op' support for the atomic so that client codebases will not need a workaround. What does your workaround look like, in case others need it as well?

When in the future we get thread support to JavaScript, having real support for atomics will be also important.

[lcoderre]

Sure, this issue's all yours ;-)

As for the workaround, it just happened to be some code that wouldn't be run in the context of my project. I simply put the lines between #ifdef EMSCRIPTEN.

[kripken]

Yeah, we don't support legalization for 100% of llvm ir, looks like we are missing atomics. But it should be easy to add - if someone can make a testcase using atomics on i64 values that would be helpful.

[dcampbell24]

@kripken can you elaborate on what you are looking for in a test case? Do we just want llvm IR assembly that calls all of the atomics? If we also want to do some basic sanity tests, should the tests be written in C or some other higher level language (e.g. Rust) that compiles to llvm IR? Must the tests somehow guarantee that the operations being performed are in fact atomic?

I looked around a little for some already existing tests and found that the llvm compiler has several atomics code generation tests under test/CodeGen. See for example test/CodeGen/X86/atomic64.ll. Could we make use of or adapt these already existing tests?

[kripken]

LLVM IR assembly is fine, C is fine as well.

Note that this bug is old, we rewrote the compiler meanwhile ;) Perhaps we already added testing for this while doing so, can grep in the emscripten and fastcomp repos.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.