LLVM with the emscripten fastcomp javascript backend https://git.amat.us/emscripten-fastcomp/atom/lib/Support/Unix?h=master 2013-11-08T23:49:37Z 2013-11-08T23:49:37Z Jan Voung jvoung@chromium.org 2013-11-08T23:49:37Z urn:sha1:46d366a017ec1b27d1ef6ce697148221d021468f Some users are reporting Mac assertion errors while linking: Assertion failed: (false && "Could not query current working directory."). Add a perror() call to see what errno is when this fails. BUG=none R=dschuff@chromium.org Review URL: https://codereview.chromium.org/66653003 2013-07-19T00:39:24Z Eli Bendersky eliben@chromium.org 2013-07-19T00:39:24Z urn:sha1:4a9f2a703db400ccf760f34101bcdd57642f96e4 sandboxed build. Condition them properly on __native_client__. 2013-07-15T23:09:15Z Eli Bendersky eliben@chromium.org 2013-07-15T23:09:15Z urn:sha1:c6cf05cb5108f356dde97c01ee4188b0671d4542 Conflicts: docs/LangRef.rst include/llvm/CodeGen/CallingConvLower.h include/llvm/IRReader/IRReader.h include/llvm/Target/TargetMachine.h lib/CodeGen/CallingConvLower.cpp lib/IRReader/IRReader.cpp lib/IRReader/LLVMBuild.txt lib/IRReader/Makefile lib/LLVMBuild.txt lib/Makefile lib/Support/MemoryBuffer.cpp lib/Support/Unix/PathV2.inc lib/Target/ARM/ARMBaseInstrInfo.cpp lib/Target/ARM/ARMISelLowering.cpp lib/Target/ARM/ARMInstrInfo.td lib/Target/ARM/ARMSubtarget.cpp lib/Target/ARM/ARMTargetMachine.cpp lib/Target/Mips/CMakeLists.txt lib/Target/Mips/MipsDelaySlotFiller.cpp lib/Target/Mips/MipsISelLowering.cpp lib/Target/Mips/MipsInstrInfo.td lib/Target/Mips/MipsSubtarget.cpp lib/Target/Mips/MipsSubtarget.h lib/Target/X86/X86FastISel.cpp lib/Target/X86/X86ISelDAGToDAG.cpp lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86InstrControl.td lib/Target/X86/X86InstrFormats.td lib/Transforms/IPO/ExtractGV.cpp lib/Transforms/InstCombine/InstCombineCompares.cpp lib/Transforms/Utils/SimplifyLibCalls.cpp test/CodeGen/X86/fast-isel-divrem.ll test/MC/ARM/data-in-code.ll tools/Makefile tools/llvm-extract/llvm-extract.cpp tools/llvm-link/CMakeLists.txt tools/opt/CMakeLists.txt tools/opt/LLVMBuild.txt tools/opt/Makefile tools/opt/opt.cpp 2013-05-04T18:52:44Z Tim Northover Tim.Northover@arm.com 2013-05-04T18:52:44Z urn:sha1:9a29cf281e5fc4e3fd4f4f83296fbc22ebfdac86 AArch64 is going to need some kind of cache-invalidation in order to successfully JIT since it has a weak memory-model. This is provided by a __clear_cache builtin in libgcc, which acts very much like the 32-bit ARM equivalent (on platforms where it exists). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181129 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-03T12:22:11Z Ulrich Weigand ulrich.weigand@de.ibm.com 2013-05-03T12:22:11Z urn:sha1:3ea50a69d75a541624a04ce957cc9eef3de639fc The llvm::sys::AddSignalHandler function (as well as related routines) in lib/Support/Unix/Signals.inc currently registers a signal handler routine via "sigaction". When this handler is called due to a SIGSEGV, SIGILL or similar signal, it will show a stack backtrace, deactivate the handler, and then simply return to the operating system. The intent is that the OS will now retry execution at the same location as before, which ought to again trigger the same error condition and cause the same signal to be delivered again. Since the hander is now deactivated, the OS will take its default action (usually, terminate the program and possibly create a core dump). However, this method doesn't work reliably on System Z: With certain signals (namely SIGILL, SIGFPE, and SIGTRAP), the program counter stored by the kernel on the signal stack frame (which is the location where execution will resume) is not the instruction that triggered the fault, but then instruction *after it*. When the LLVM signal handler simply returns to the kernel, execution will then resume at *that* address, which will not trigger the problem again, but simply go on and execute potentially unrelated code leading to random errors afterwards. To fix this, the patch simply goes and re-raises the signal in question directly from the handler instead of returning from it. This is done only on System Z and only for those signals that have this particular problem. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181010 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-28T07:47:04Z Benjamin Kramer benny.kra@googlemail.com 2013-04-28T07:47:04Z urn:sha1:d9225188449f0ed381b5e0806527daf77a229d42 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180688 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-27T22:32:54Z Joerg Sonnenberger joerg@bec.de 2013-04-27T22:32:54Z urn:sha1:78a9b434e1e8cd627690bb6d942b2a0580e5fbc5 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180686 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-27T22:12:32Z Joerg Sonnenberger joerg@bec.de 2013-04-27T22:12:32Z urn:sha1:dfa0e92fa034019252305d62e42387bf6a758500 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180684 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-11T14:06:34Z Rafael Espindola rafael.espindola@gmail.com 2013-04-11T14:06:34Z urn:sha1:845a932af74ecbd2a20af5751dd61fa8cf2246f5 This will be used in clang to decide if it should create an @file or not. It will be tested on the clang side. Patch by Nathan Froyd. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179285 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-05T20:48:36Z Douglas Gregor dgregor@apple.com 2013-04-05T20:48:36Z urn:sha1:0591f19c8b84311288ef19f76952c334b9730681 If the directory that will contain the unique file doesn't exist when we tried to create the file, but another process creates it before we get a chance to try creating it, we would bail out rather than try to create the unique file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178908 91177308-0d34-0410-b5e6-96231b3b80d8