emscripten clang https://git.amat.us/emscripten-fastcomp-clang/atom/lib?h=master 2014-04-25T23:00:38Z 2014-04-25T23:00:38Z Dan Gohman sunfish@mozilla.com 2014-04-25T23:00:38Z urn:sha1:364355da26053c321180fa31ecd731d36c4cffae Emscripten uses the ARM ABI for pointers to member functions and doesn't require that member functions are aligned. 2014-04-25T22:51:06Z Dan Gohman sunfish@mozilla.com 2014-04-25T22:51:06Z urn:sha1:ad32fdb927a37dba26cb8b56f3a6b11667fe6584 Emscripten uses the Itanium C++ ABI for most things, except that it uses ARM C++ ABI pointers to member functions, to avoid the overhead of aligning functions. 2014-04-10T00:19:03Z Alon Zakai alonzakai@gmail.com 2014-04-10T00:19:03Z urn:sha1:f1e7a40a73073cf492a7411acc049af0c729fe8a 2014-03-03T23:00:57Z Dan Gohman sunfish@mozilla.com 2014-03-03T22:09:52Z urn:sha1:d159899bf2ebd04f7b6620206223d4025cd34c5a 2014-03-03T23:00:22Z Dan Gohman sunfish@mozilla.com 2014-03-03T22:08:08Z urn:sha1:f92a8f0ef8f7b349d653e97a8fb154719ef6117f Also, fix the way we override DefaultABIInfo methods, since classifyArgumentType and classifyReturnType are not actually virtual. Also, DefaultABIInfo does the right thing for floating-point types, so we don't need to special-case them. 2014-02-28T21:30:42Z Dan Gohman sunfish@mozilla.com 2014-02-28T21:07:59Z urn:sha1:f59469c5a434866f9a69439555a3684faa16e7fc For us, staying in sync with upstream on issues related to the memory model is more important. None of clang, gcc, nor icc appear to offer these features. If such features are desirable, they should ideally be implemented in upstream clang, in a target-independent way, since this issue would affect users of all platforms which support threads, not just PNaCl or Emscripten. 2014-02-25T01:32:55Z Dan Gohman sunfish@google.com 2014-02-24T16:50:27Z urn:sha1:632c823b8bfd3fd5a4b77628eddd6161c5d8367e This is pretty minimal right now; eventually this may subsume code currently in the emscripten wrapper scripts. 2014-02-25T01:32:54Z Dan Gohman sunfish@google.com 2014-02-22T00:09:43Z urn:sha1:f6e2fddff6294c1c2ec2f9602c30ff680359ed19 Notable changes from le32-unknown-nacl so far include: - Set i32 as the legal integer set, to help the optimizer avoid creating needlessly inefficient code for asm.js. - We can use llvm.pow. - Don't predefine __ELF__ or __pnacl__ so that we don't need to undefine them later. - Do predefine asm.js and Emscripten macros, so that we don't need to define them later. - Don't provide __has_feature(pnacl). 2013-11-08T23:52:28Z JF Bastien jfb@chromium.org 2013-11-08T23:52:28Z urn:sha1:a963b803407c9d1cac644cc425004e0ccd28fa45 For integer types of sizes 1, 2, 4 and 8, libcompiler-rt (and libgcc) provide atomic functions that pass parameters by value and return results directly. libgcc and libcompiler-rt only provide optimized libcalls for __atomic_fetch_*, as generic libcalls on non-integer types would make little sense. This means that we can finally make __atomic_fetch_* work on architectures for which we don't provide these operations as builtins (e.g. ARM). This should fix the dreaded "cannot compile this atomic library call yet" error that would pop up once every while. These code generation issues are encountered because PNaCl doesn't inline some of the atomic instructions, whereas other targets do. This patch is just after the 3.3 branch and applies cleanly, but it doesn't fix all issues: there is still at least one with atomic operations on pointers which isn't as clean to fix as applying one patch, so I'll leave that one as-is for now. R=dschuff@chromium.org BUG= https://code.google.com/p/nativeclient/issues/detail?id=3623 TEST= ./pnacl/scripts/llvm-test.py --libcxx-tests Review URL: https://codereview.chromium.org/59793007 2013-10-28T15:58:05Z JF Bastien jfb@chromium.org 2013-10-28T15:58:05Z urn:sha1:5b8e932d70fcf281e193aebfd0d3ac55d057f2da This is needed for libc++ testing with newlib. R=dschuff@chromium.org BUG= https://code.google.com/p/nativeclient/issues/detail?id=3623 TEST= ./pnacl/scripts/llvm-test.py --libcxx-tests Review URL: https://codereview.chromium.org/47573003