summaryrefslogtreecommitdiffstats
path: root/gnu/llvm/lib/CodeGen/StackProtector.cpp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove LLVM 8.0.1 files.patrick2020-08-031-541/+0
|
* Merge LLVM 8.0.0 release.patrick2019-06-231-17/+24
| | | | | | | | | Prepared with help from jsg@ and mortimer@ Tested on amd64 by bcallah@, krw@, naddy@ Tested on arm64 by patrick@ Tested on macppc by kettenis@ Tested on octeon by visa@ Tested on sparc64 by claudio@
* Merge LLVM 7.0.1 release.patrick2019-01-271-35/+44
| | | | | With fixes from mortimer@ (thanks!) Tested by many, especially naddy@ (thanks!)
* Merge LLVM 6.0.0 release.patrick2018-04-061-23/+35
|
* Merge LLVM 5.0.0 release.patrick2017-10-041-15/+62
|
* Merge LLVM 4.0.0 rc1patrick2017-01-241-6/+1
|
* Merge LLVM 3.9.1patrick2017-01-141-111/+91
|
* Backport https://reviews.llvm.org/rL279449 from upstreamstefan2016-09-071-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | ok pascal@ Original commit message: [SSP] Do not set __guard_local to hidden for OpenBSD SSP guard_local is defined as long on OpenBSD. If the source file contains a definition of guard_local, it mismatches with the int8 pointer type used in LLVM. In that case, Module::getOrInsertGlobal() returns a cast operation instead of a GlobalVariable. Trying to set the visibility on the cast operation leads to random segfaults (seen when compiling the OpenBSD kernel, which also runs with stack protection). In the kernel, the hidden attribute does not matter. For userspace code, guard_local is defined as hidden in the startup code. If a program re-defines guard_local, the definition from the startup code will either win or the linker complains about multiple definitions (depending on whether the re-defined __guard_local is placed in the common segment or not). It also matches what gcc on OpenBSD does.
* Use the space freed up by sparc and zaurus to import LLVM.pascal2016-09-031-0/+493
ok hackroom@