jgravelle-google abandoned this revision.
jgravelle-google added a comment.
Abandoning this in favor of https://github.com/kripken/emscripten/pull/4846
https://reviews.llvm.org/D28381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://li
jgravelle-google added a comment.
In https://reviews.llvm.org/D28381#637915, @sunfish wrote:
> Would it be difficult to enable atomic.c in Emscripten's compiler-rt build,
> to define these libcalls (assuming that the problem is just that they're not
> currently defined)?
Tried it and it seems
sunfish added a comment.
(Emscripten does set the thread model.)
Whether WebAssembly should provide 64-bit atomics when on hardware where
they're not lock-free is an interesting wasm design question, and the code here
and in target-independent parts of clang may need to be changed as a result
dschuff added inline comments.
Comment at: test/Preprocessor/init.c:8613
// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_INT_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
// WEBASSEMBLY32-NEXT:
dschuff added a comment.
Making it guarded by thread model makes sense, although I'm not exactly sure
whether emscripten sets that or not. But even when we do start prototyping
actual atomics, I had assumed we'd be defining i64 atomics symmetrically along
with i32 atomics, in which case we woul
sunfish added a comment.
Since we may soon have people prototyping actual atomics, I'd prefer to find a
less invasive way to fix this.
Would it be difficult to enable atomic.c in Emscripten's compiler-rt build, to
define these libcalls (assuming that the problem is just that they're not
curren
jgravelle-google created this revision.
jgravelle-google added reviewers: dschuff, sunfish.
jgravelle-google added a subscriber: cfe-commits.
Herald added a subscriber: jfb.
Wasm MVP doesn't have any mechanism to respect atomicity. Skip emitting
libcalls for the time being.
https://reviews.llvm.
