http://llvm.org https://git.amat.us/llvm/atom/lib/Support/Unix?h=release_33 2013-05-04T18:52:44Z 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 2013-03-26T01:27:52Z Nick Lewycky nicholas@mxc.ca 2013-03-26T01:27:52Z urn:sha1:d5e1be03eda2e8036f136fdf12a5f5d9e1e684d8 it's only really useful if you're going to crash anyways. Use it in the pretty stack trace printer to kill the compiler if we hang while printing the stack trace. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177962 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-14T19:01:00Z Akira Hatanaka ahatanaka@mips.com 2013-03-14T19:01:00Z urn:sha1:21eecf43848fdc94bed5683c16a7f3d8ce6d1a70 Patch by Stephen Hines. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177101 91177308-0d34-0410-b5e6-96231b3b80d8 2013-03-14T00:20:10Z Michael J. Spencer bigcheesegs@gmail.com 2013-03-14T00:20:10Z urn:sha1:cc3a595ab938352f3acf8652c5858ddf879524a5 Clients of MemoryBuffer::getOpenFile expect it not to take ownership of the file descriptor passed in. So don't. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176995 91177308-0d34-0410-b5e6-96231b3b80d8