summaryrefslogtreecommitdiffstats
path: root/gnu/llvm/lib/CodeGen (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Use int3 trap padding between functions instead of trapsleds with a leading jump.mortimer2017-08-011-1/+28
| | | | ok deraadt@
* Import LLVM 4.0.0 release including clang and lld.patrick2017-03-1415-142/+213
|
* Merge LLVM 4.0.0 rc1patrick2017-01-243-81/+275
|
* Import LLVM 4.0.0 rc1 including clang and lld to help the currentpatrick2017-01-24200-7570/+19563
| | | | development effort on OpenBSD/arm64.
* Restore setting the visibility of __guard_local to hidden for betterguenther2017-01-201-1/+4
| | | | | | | code generation. Use dyn_case_or_null instead of a static cast to solve the crashes in the previous code. ok stefan@ kettenis@
* Merge LLVM 3.9.1patrick2017-01-1416-1807/+92
|
* Import LLVM 3.9.1 including clang and lld.patrick2017-01-14199-11664/+26288
|
* 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-03232-0/+172476
ok hackroom@