LLVM_COMPLETE_INSTALLATION #29
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
------------------------------------------------------------------------ r351459 | arphaman | 2019-01-17 19:12:45 +0100 (Thu, 17 Jan 2019) | 13 lines [ObjC] Follow-up r350768 and allow the use of unavailable methods that are declared in a parent class from within the @implementation context This commit extends r350768 and allows the use of methods marked as unavailable that are declared in a parent class/category from within the @implementation of the class where the method is marked as unavailable. This allows users to call init that's marked as unavailable even if they don't define it. rdar://47134898 Differential Revision: https://reviews.llvm.org/D56816 ------------------------------------------------------------------------ llvm-svn: 351535
------------------------------------------------------------------------ r351504 | brad | 2019-01-18 02:36:58 +0100 (Fri, 18 Jan 2019) | 2 lines Use llvm::VersionTuple instead of manual version marshalling ------------------------------------------------------------------------ llvm-svn: 351536
------------------------------------------------------------------------ r351463 | eugenezelenko | 2019-01-17 19:31:34 +0100 (Thu, 17 Jan 2019) | 6 lines [Documentation] Add a chapter about Clang-tidy integrations. Patch by Marina Kalashina. Differential Revision: https://reviews.llvm.org/D54945 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r351466 | eugenezelenko | 2019-01-17 20:35:39 +0100 (Thu, 17 Jan 2019) | 2 lines [Documentation] Fix link in docs/clang-tidy/Contributing.rst. ------------------------------------------------------------------------ ------------------------------------------------------------------------ r351467 | eugenezelenko | 2019-01-17 20:47:44 +0100 (Thu, 17 Jan 2019) | 2 lines [Documentation] Another attempt to fix link in docs/clang-tidy/Contributing.rst. Use HTTPS for links. ------------------------------------------------------------------------ ------------------------------------------------------------------------ r351468 | eugenezelenko | 2019-01-17 21:00:23 +0100 (Thu, 17 Jan 2019) | 2 lines [Documentation] Fix another link in docs/clang-tidy/Contributing.rst. ------------------------------------------------------------------------ llvm-svn: 351538
------------------------------------------------------------------------ r351426 | d0k | 2019-01-17 11:25:18 +0100 (Thu, 17 Jan 2019) | 1 line [MC] Remove unused variable ------------------------------------------------------------------------ llvm-svn: 351543
------------------------------------------------------------------------ r351580 | kli | 2019-01-18 20:57:37 +0100 (Fri, 18 Jan 2019) | 4 lines [OPENMP][DOCS] Release notes/OpenMP support updates, NFC. Differential Revision: https://reviews.llvm.org/D56733 ------------------------------------------------------------------------ llvm-svn: 351839
------------------------------------------------------------------------ r351686 | vmiklos | 2019-01-20 15:28:27 +0100 (Sun, 20 Jan 2019) | 5 lines [clang-tidy] misc-non-private-member-variables-in-classes: ignore implicit methods Otherwise we don't warn on a struct containing a single public int, but we warn on a struct containing a single public std::string, which is inconsistent. ------------------------------------------------------------------------ llvm-svn: 351844
------------------------------------------------------------------------ r351753 | spatel | 2019-01-21 18:30:14 +0100 (Mon, 21 Jan 2019) | 8 lines [DAGCombiner] fix crash when converting build vector to shuffle The regression test is reduced from the example shown in D56281. This does raise a question as noted in the test file: do we want to handle this pattern? I don't have a motivating example for that on x86 yet, but it seems like we could have that pattern there too, so we could avoid the back-and-forth using a shuffle. ------------------------------------------------------------------------ llvm-svn: 351857
------------------------------------------------------------------------ r351754 | spatel | 2019-01-21 18:46:35 +0100 (Mon, 21 Jan 2019) | 6 lines [AArch64] add more tests for buildvec to shuffle transform; NFC These are copied from the sibling x86 file. I'm not sure which of the current outputs (if any) is considered optimal, but someone more familiar with AArch may want to take a look. ------------------------------------------------------------------------ llvm-svn: 351858
------------------------------------------------------------------------ r351788 | kadircet | 2019-01-22 10:10:20 +0100 (Tue, 22 Jan 2019) | 15 lines [clangd] Filter out plugin related flags and move all commandline manipulations into OverlayCDB. Summary: Some projects make use of clang plugins when building, but clangd is not aware of those plugins therefore can't work with the same compile command arguments. There were multiple places clangd performed commandline manipulations, this one also moves them all into OverlayCDB. Reviewers: ilya-biryukov Subscribers: klimek, sammccall, ioeric, MaskRay, jkorous, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D56841 ------------------------------------------------------------------------ llvm-svn: 351860
…e the last release Differential Revision: https://reviews.llvm.org/D57005 llvm-svn: 351868
…st release Differential Revision: https://reviews.llvm.org/D57003 llvm-svn: 351870
…st release Differential Revision: https://reviews.llvm.org/D57004 llvm-svn: 351872
------------------------------------------------------------------------ r351531 | kadircet | 2019-01-18 10:00:31 +0100 (Fri, 18 Jan 2019) | 11 lines [tooling] Add a new argument adjuster for deleting plugin related command line args Summary: Currently both clangd and clang-tidy makes use of this mechanism so putting it into tooling so that all tools can make use of it. Reviewers: ilya-biryukov, sammccall Subscribers: ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D56856 ------------------------------------------------------------------------ llvm-svn: 351961
------------------------------------------------------------------------ r351738 | kadircet | 2019-01-21 11:10:18 +0100 (Mon, 21 Jan 2019) | 9 lines [clang-tidy] Use getStripPluginsAdjuster Summary: See rC351531 for the introduction of getStripPluginsAdjuster. Reviewers: alexfh Subscribers: xazax.hun, cfe-commits Differential Revision: https://reviews.llvm.org/D56902 ------------------------------------------------------------------------ llvm-svn: 351962
------------------------------------------------------------------------ r351898 | pcc | 2019-01-23 00:51:35 +0100 (Wed, 23 Jan 2019) | 13 lines COFF, ELF: Adjust ICF hash computation to account for self relocations. It turns out that sections in PGO instrumented object files on Windows contain a large number of relocations pointing to themselves. With r347429 this can cause many sections to receive the same hash (usually zero) as a result of a section's hash being xor'ed with itself. This patch causes the COFF and ELF linkers to avoid this problem by adding the hash of the relocated section instead of xor'ing it. On my machine this causes the regressing test case provided by Mozilla to terminate in 2m41s. Differential Revision: https://reviews.llvm.org/D56955 ------------------------------------------------------------------------ llvm-svn: 351963
------------------------------------------------------------------------ r351899 | pcc | 2019-01-23 00:54:49 +0100 (Wed, 23 Jan 2019) | 26 lines COFF, ELF: ICF: Perform 2 rounds of relocation hash propagation. LLD's performance on PGO instrumented Windows binaries was still not great even with the fix in D56955; out of the 2m41s linker runtime, around 2 minutes were still being spent in ICF. I looked into this more closely and discovered that the vast majority of the runtime was being spent segregating .pdata sections with the following relocation chain: .pdata -> identical .text -> unique PGO counter (not eligible for ICF) This patch causes us to perform 2 rounds of relocation hash propagation, which allows the hash for the .pdata sections to incorporate the identifier from the PGO counter. With that, the amount of time spent in ICF was reduced to about 2 seconds. I also found that the same change led to a significant ICF performance improvement in a regular release build of Chromium's chrome_child.dll, where ICF time was reduced from around 1s to around 700ms. With the same change applied to the ELF linker, median of 100 runs for lld-speed-test/chrome reduced from 4.53s to 4.45s on my machine. I also experimented with increasing the number of propagation rounds further, but I did not observe any further significant performance improvements linking Chromium or Firefox. Differential Revision: https://reviews.llvm.org/D56986 ------------------------------------------------------------------------ llvm-svn: 351964
------------------------------------------------------------------------ r351670 | ericwf | 2019-01-20 02:21:35 +0100 (Sun, 20 Jan 2019) | 7 lines Fix aligned allocation availability XFAILs after D56445. D56445 bumped the minimum Mac OS X version required for aligned allocation from 10.13 to 10.14. This caused libc++ tests depending on the old value to break. This patch updates the XFAILs for those tests to include 10.13. ------------------------------------------------------------------------ llvm-svn: 351980
------------------------------------------------------------------------ r351930 | kbeyls | 2019-01-23 09:18:39 +0100 (Wed, 23 Jan 2019) | 30 lines [SLH] AArch64: correctly pick temporary register to mask SP As part of speculation hardening, the stack pointer gets masked with the taint register (X16) before a function call or before a function return. Since there are no instructions that can directly mask writing to the stack pointer, the stack pointer must first be transferred to another register, where it can be masked, before that value is transferred back to the stack pointer. Before, that temporary register was always picked to be x17, since the ABI allows clobbering x17 on any function call, resulting in the following instruction pattern being inserted before function calls and returns/tail calls: mov x17, sp and x17, x17, x16 mov sp, x17 However, x17 can be live in those locations, for example when the call is an indirect call, using x17 as the target address (blr x17). To fix this, this patch looks for an available register just before the call or terminator instruction and uses that. In the rare case when no register turns out to be available (this situation is only encountered twice across the whole test-suite), just insert a full speculation barrier at the start of the basic block where this occurs. Differential Revision: https://reviews.llvm.org/D56717 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r351932 | kbeyls | 2019-01-23 10:10:12 +0100 (Wed, 23 Jan 2019) | 3 lines [SLH][AArch64] Remove accidentally retained -debug-only line from test. ------------------------------------------------------------------------ llvm-svn: 352115
------------------------------------------------------------------------ r352040 | ibiryukov | 2019-01-24 11:41:43 +0100 (Thu, 24 Jan 2019) | 9 lines [CodeComplete] [clangd] Fix crash on ValueDecl with a null type Reviewers: kadircet Reviewed By: kadircet Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D57093 ------------------------------------------------------------------------ llvm-svn: 352118
------------------------------------------------------------------------ r352040 | ibiryukov | 2019-01-24 11:41:43 +0100 (Thu, 24 Jan 2019) | 9 lines [CodeComplete] [clangd] Fix crash on ValueDecl with a null type Reviewers: kadircet Reviewed By: kadircet Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D57093 ------------------------------------------------------------------------ llvm-svn: 352120
------------------------------------------------------------------------ r352102 | rsmith | 2019-01-24 21:52:56 +0100 (Thu, 24 Jan 2019) | 2 lines Add a triple to this test so it passes for targets where alignof(double) really should be equal to alignof(float). ------------------------------------------------------------------------ llvm-svn: 352132
------------------------------------------------------------------------ r352116 | mgorny | 2019-01-24 23:20:47 +0100 (Thu, 24 Jan 2019) | 9 lines [Process/NetBSD] Add missing linkage to -lutil Add missing linkage to fix build failure with LLD: ld: error: undefined symbol: kinfo_getvmmap >>> referenced by NativeProcessNetBSD.cpp >>> NativeProcessNetBSD.cpp.o:(lldb_private::process_netbsd::NativeProcessNetBSD::PopulateMemoryRegionCache()) in archive lib/liblldbPluginProcessNetBSD.a Differential Revision: https://reviews.llvm.org/D57193 ------------------------------------------------------------------------ llvm-svn: 352134
------------------------------------------------------------------------ r352082 | ruiu | 2019-01-24 20:02:31 +0100 (Thu, 24 Jan 2019) | 15 lines Fix broken export table if .rdata is merged with .text. Previously, we assumed that .rdata is zero-filled, so when writing an COFF import table, we didn't write anything if the data is zero. That assumption was wrong because .rdata can be merged with .text. If .rdata is merged with .text, they are initialized with 0xcc which is a trap instruction. This patch removes that assumption from code. Should be merged to 8.0 branch as this is a regression. Fixes https://bugs.llvm.org/show_bug.cgi?id=39826 Differential Revision: https://reviews.llvm.org/D57168 ------------------------------------------------------------------------ llvm-svn: 352135
------------------------------------------------------------------------
r351485 | vstefanovic | 2019-01-17 22:50:37 +0100 (Thu, 17 Jan 2019) | 10 lines
[mips] Emit .reloc R_{MICRO}MIPS_JALR along with j(al)r(c) $25
The callee address is added as an optional operand (MCSymbol) in
AdjustInstrPostInstrSelection() and then used by asm printer to insert:
'.reloc tmplabel, R_MIPS_JALR, symbol
tmplabel:'.
Controlled with '-mips-jalr-reloc', default is true.
Differential revision: https://reviews.llvm.org/D56694
------------------------------------------------------------------------
llvm-svn: 352137
------------------------------------------------------------------------
r351579 | vstefanovic | 2019-01-18 20:54:51 +0100 (Fri, 18 Jan 2019) | 9 lines
[mips] Add '-mrelax-pic-calls', '-mno-relax-pic-calls'
These two options enable/disable emission of R_{MICRO}MIPS_JALR fixups along
with PIC calls. The linker may then try to turn PIC calls into direct jumps.
By default, these fixups do get emitted by the backend, use
'-mno-relax-pic-calls' to omit them.
Differential revision: https://reviews.llvm.org/D56878
------------------------------------------------------------------------
llvm-svn: 352139
------------------------------------------------------------------------ r352034 | atanasyan | 2019-01-24 10:13:14 +0100 (Thu, 24 Jan 2019) | 18 lines Reapply: [mips] Handle MipsMCExpr sub-expression for the MEK_DTPREL tag This reapplies commit r351987 with a failed test fix. Now the test accepts both DW_OP_GNU_push_tls_address and DW_OP_form_tls_address opcode. Original commit message: ``` This is a fix for a regression introduced by the rL348194 commit. In that change new type (MEK_DTPREL) of MipsMCExpr expression was added, but in some places of the code this type of expression considered as unexpected. This change fixes the bug. The MEK_DTPREL type of expression is used for marking TLS DIEExpr only and contains a regular sub-expression. Where we need to handle the expression, we retrieve the sub-expression and handle it in a common way. ``` ------------------------------------------------------------------------ llvm-svn: 352140
------------------------------------------------------------------------ r352068 | serge_sans_paille | 2019-01-24 18:56:08 +0100 (Thu, 24 Jan 2019) | 7 lines Partial support of SHT_GROUP without flag This does *not* implement full SHT_GROUP semantic, yet it is a simple step forward: Sections within a group are still considered valid, but they do not behave as specified by the standard in case of garbage collection. Differential Revision: https://reviews.llvm.org/D56437 ------------------------------------------------------------------------ llvm-svn: 352218
------------------------------------------------------------------------ r352079 | sammccall | 2019-01-24 19:55:24 +0100 (Thu, 24 Jan 2019) | 33 lines [FileManager] Revert r347205 to avoid PCH file-descriptor leak. Summary: r347205 fixed a bug in FileManager: first calling getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in the file not being open. Unfortunately, some code was (inadvertently?) relying on this bug: when building with a PCH, the file entries are obtained first by passing shouldOpen=false, and then later shouldOpen=true, without any intention of reading them. After r347205, they do get unneccesarily opened. Aside from extra operations, this means they need to be closed. Normally files are closed when their contents are read. As these files are never read, they stay open until clang exits. On platforms with a low open-files limit (e.g. Mac), this can lead to spurious file-not-found errors when building large projects with PCH enabled, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=924225 Fixing the callsites to pass shouldOpen=false when the file won't be read is not quite trivial (that info isn't available at the direct callsite), and passing shouldOpen=false is a performance regression (it results in open+fstat pairs being replaced by stat+open). So an ideal fix is going to be a little risky and we need some fix soon (especially for the llvm 8 branch). The problem addressed by r347205 is rare and has only been observed in clangd. It was present in llvm-7, so we can live with it for now. Reviewers: bkramer, thakis Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D57165 ------------------------------------------------------------------------ llvm-svn: 352225
------------------------------------------------------------------------ r352204 | sammccall | 2019-01-25 16:05:33 +0100 (Fri, 25 Jan 2019) | 7 lines [JSON] Work around excess-precision issue when comparing T_Integer numbers. Reviewers: bkramer Subscribers: kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D57237 ------------------------------------------------------------------------ llvm-svn: 352233
------------------------------------------------------------------------ r352234 | dim | 2019-01-25 20:36:47 +0100 (Fri, 25 Jan 2019) | 38 lines Fix XRayTest link on FreeBSD (and likely NetBSD too) Summary: As reported on llvm-testers, during 8.0.0-rc1 testing I got errors while building of `XRayTest`, during `check-all`: ``` [100%] Generating XRayTest-x86_64-Test /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)': Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace' Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)' clang-8: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1 gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors. gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2 gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors. gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2 gmake[1]: Target 'check-all' not remade because of errors. gmake: *** [Makefile:277: check-all] Error 2 [Release Phase3] check-all failed ``` This is because the `backtrace` function requires `-lexecinfo` on BSD platforms. To fix this, detect the `execinfo` library in `cmake/config-ix.cmake`, and add it to the unit test link flags. Additionally, since the code in `sys::PrintStackTrace` makes use of `itaniumDemangle`, also add `-lLLVMDemangle`. (Note that this is more of a general problem with libLLVMSupport, but I'm looking for a quick fix now so it can be merged to the 8.0 branch.) Reviewers: dberris, hans, mgorny, samsonov Reviewed By: dberris Subscribers: krytarowski, delcypher, erik.pilkington, #sanitizers, emaste, llvm-commits Differential Revision: https://reviews.llvm.org/D57181 ------------------------------------------------------------------------ llvm-svn: 352251
llvm-svn: 362635
------------------------------------------------------------------------ r359898 | arsenm | 2019-05-03 08:21:53 -0700 (Fri, 03 May 2019) | 3 lines AMDGPU: Support shrinking add with FI in SIFoldOperands Avoids test regression in a future patch ------------------------------------------------------------------------ llvm-svn: 362648
------------------------------------------------------------------------ r359899 | arsenm | 2019-05-03 08:37:07 -0700 (Fri, 03 May 2019) | 7 lines AMDGPU: Select VOP3 form of sub The VOP3 form should always be the preferred selection form to be shrunk later. The r600 sub test needs to be split out because it asserts on the arguments in the new test during the calling convention lowering. ------------------------------------------------------------------------ llvm-svn: 362654
------------------------------------------------------------------------ r360293 | arsenm | 2019-05-08 15:09:57 -0700 (Wed, 08 May 2019) | 21 lines AMDGPU: Select VOP3 form of add The VOP3 form should always be the preferred selection, to be shrunk later. This should only be an optimization issue, but this partially works around a problem from clobbering VCC when SIFixSGPRCopies rewrites an SCC defining operation directly to VCC. 3 of the testcases are regressions from failing to fold the immediate in cases it should. These can be avoided by improving the VCC liveness handling in SIFoldOperands. Simply increasing the threshold to computeRegisterLiveness works, although this is common enough that VCC liveness should probably be tracked throughout the pass. The hack of leaving behind an implicit_def instruction to avoid breaking iterator wastes instruction count, which inhibits finding the VCC def in long chains of adds. Doing this however exposes different, worse looking regressions from poor scheduling behavior. This could probably be avoided around by forcing the shrink of the addc here, but the scheduler should probably be fixed. The r600 add test needs to be split out because it asserts on the arguments in the new test during the calling convention lowering. ------------------------------------------------------------------------ llvm-svn: 362658
------------------------------------------------------------------------ r360439 | maskray | 2019-05-10 09:24:57 -0700 (Fri, 10 May 2019) | 8 lines [llvm-objdump] Print st_other Add support for ".hidden" ".internal" ".protected" and " 0x%02x" for other st_other bits used by some architectures. Reviewed By: sfertile Differential Revision: https://reviews.llvm.org/D61718 ------------------------------------------------------------------------ llvm-svn: 362668
------------------------------------------------------------------------ r360442 | maskray | 2019-05-10 10:09:25 -0700 (Fri, 10 May 2019) | 12 lines [MC][ELF] Copy top 3 bits of st_other to .symver aliases On PowerPC64 ELFv2 ABI, the top 3 bits of st_other encode the local entry offset. A versioned symbol alias created by .symver should copy the bits from the source symbol. This partly fixes PR41048. A full fix needs tracking of .set assignments and updating st_other fields when finish() is called, see D56586. Patch by Alfredo Dal'Ava Júnior Differential Revision: https://reviews.llvm.org/D59436 ------------------------------------------------------------------------ llvm-svn: 362669
llvm-svn: 362670
------------------------------------------------------------------------ r361237 | maskray | 2019-05-21 03:41:25 -0700 (Tue, 21 May 2019) | 14 lines [PPC64] Update LocalEntry from assigned symbols On PowerPC64 ELFv2 ABI, functions may have 2 entry points: global and local. The local entry point location of a function is stored in the st_other field of the symbol, as an offset relative to the global entry point. In order to make symbol assignments (e.g. .equ/.set) work properly with this, PPCTargetELFStreamer already copies the local entry bits from the source symbol to the destination one, on emitAssignment(). The problem is that this copy is performed only at the assignment location, where the source symbol may not yet have processed the .localentry directive, that sets the local entry. This may cause the destination symbol to end up with wrong local entry information. Other symbol info is not affected by this because, in this case, the destination symbol value is actually a symbol reference. This change keeps track of these assignments, and update all needed st_other fields when finish() is called. Patch by Leandro Lupori! Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D56586 ------------------------------------------------------------------------ llvm-svn: 362671
------------------------------------------------------------------------ r355154 | joerg | 2019-02-28 15:33:09 -0800 (Thu, 28 Feb 2019) | 2 lines [PPC] Secure PLT only has meaning for PIC ------------------------------------------------------------------------ llvm-svn: 362729
------------------------------------------------------------------------ r353905 | hubert.reinterpretcast | 2019-02-12 16:55:30 -0800 (Tue, 12 Feb 2019) | 17 lines [xray][tests][RHDTS] Add -lstdc++ after LLVM libs, resolving link error with RHDTS Summary: A link error was encountered when using the Red Hat Developer Toolset. In the RHDTS, `libstdc++.so` is a linker script that may resolve symbols to a static library. This patch places `-lstdc++` later in the ordering. Reviewers: sfertile, nemanjai, tstellar, dberris Reviewed By: dberris Subscribers: dberris, mgorny, delcypher, jdoerfert, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D58144 ------------------------------------------------------------------------ llvm-svn: 362765
------------------------------------------------------------------------
r361090 | maskray | 2019-05-17 20:16:00 -0700 (Fri, 17 May 2019) | 34 lines
[ARM][AArch64] Revert Android Bionic PT_TLS overaligning hack
This reverts D53906.
D53906 increased p_align of PT_TLS on ARM/AArch64 to 32/64 to make the
static TLS layout compatible with Android Bionic's ELF TLS. However,
this may cause glibc ARM/AArch64 programs to crash (see PR41527).
The faulty PT_TLS in the executable satisfies p_vaddr%p_align != 0. The
remainder is normally 0 but may be non-zero with the hack in place. The
problem is that we increase PT_TLS's p_align after OutputSections'
addresses are fixed (assignAddress()). It is possible that
p_vaddr%old_p_align = 0 while p_vaddr%new_p_align != 0.
For a thread local variable defined in the executable, lld computed TLS
offset (local exec) is different from glibc computed TLS offset from
another module (initial exec/generic dynamic). Note: PR41527 said the
bug affects initial exec but actually generic dynamic is affected as
well.
(glibc is correct in that it compute offsets that satisfy
`offset%p_align == p_vaddr%p_align`, which is a basic ELF requirement.
This hack appears to work on FreeBSD rtld, musl<=1.1.22, and Bionic, but
that is just because they (and lld) incorrectly compute offsets that
satisfy `offset%p_align = 0` instead.)
Android developers are fine to revert this patch, carry this patch in
their tree before figuring out a long-term solution (e.g. a dummy .tdata
with sh_addralign=64 sh_size={0,1} in crtbegin*.o files. The overhead is
now insignificant after D62059).
Reviewed By: rprichard, srhines
Differential Revision: https://reviews.llvm.org/D62055
------------------------------------------------------------------------
llvm-svn: 362858
------------------------------------------------------------------------ r351577 | ssijaric | 2019-01-18 11:34:20 -0800 (Fri, 18 Jan 2019) | 5 lines Fix the buildbot issue introduced by r351421 The EXPENSIVE_CHECK x86_64 Windows buildbot is failing due to this change. Fix the map access. ------------------------------------------------------------------------ llvm-svn: 363006
------------------------------------------------------------------------ r358042 | jimlin | 2019-04-09 18:56:32 -0700 (Tue, 09 Apr 2019) | 34 lines [Sparc] Fix incorrect MI insertion position for spilling f128. Summary: Obviously, new built MI (sethi+add or sethi+xor+add) for constructing large offset should be inserted before new created MI for storing even register into memory. So the insertion position should be *StMI instead of II. before fixed: std %f0, [%g1+80] sethi 4, %g1 <<< add %g1, %sp, %g1 <<< this two instructions should be put before "std %f0, [%g1+80]". sethi 4, %g1 add %g1, %sp, %g1 std %f2, [%g1+88] after fixed: sethi 4, %g1 add %g1, %sp, %g1 std %f0, [%g1+80] sethi 4, %g1 add %g1, %sp, %g1 std %f2, [%g1+88] Reviewers: venkatra, jyknight Reviewed By: jyknight Subscribers: jyknight, fedor.sergeev, jrtc27, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60397 ------------------------------------------------------------------------ llvm-svn: 363010
llvm-svn: 363027
------------------------------------------------------------------------ r360862 | mstorsjo | 2019-05-15 23:49:20 -0700 (Wed, 15 May 2019) | 12 lines [PPC] Fix 32-bit build of libunwind Clang integrated assembler was unable to build libunwind PPC32 assembly code, present in functions used to save/restore register context. This change consists in replacing the assembly style used in libunwind source, to one that is compatible with both Clang integrated assembler as well as GNU assembler. Patch by Leandro Lupori! Differential Revision: https://reviews.llvm.org/D61792 ------------------------------------------------------------------------ llvm-svn: 363030
------------------------------------------------------------------------ r361158 | jprotze | 2019-05-20 07:21:42 -0700 (Mon, 20 May 2019) | 11 lines [OpenMP][OMPT] Fix locking testcases for 32 bit architectures https://reviews.llvm.org/D58454 did not fix the problem for a typical use case of building LLVM with gcc or icc and then testing with the newly built clang compiler. The compilers do not agree on how to extend a 32-bit pointer to uint64, so make the pointer unsigned first, before adjusting the size. Patch by Joachim Protze Differential Revision: https://reviews.llvm.org/D58506 ------------------------------------------------------------------------ llvm-svn: 363628
------------------------------------------------------------------------ r359094 | maskray | 2019-04-24 07:03:30 -0700 (Wed, 24 Apr 2019) | 12 lines [PPC64] Consider localentry offset when computing branch distance Summary: We don't take localentry offset into account, and thus may fail to create a long branch when the gap is just a few bytes smaller than 2^25. relocation R_PPC64_REL24 out of range: 33554432 is not in [-33554432, 33554431] relocation R_PPC64_REL24 out of range: 33554436 is not in [-33554432, 33554431] Fix that by adding the offset to the symbol VA. Differential Revision: https://reviews.llvm.org/D61058 ------------------------------------------------------------------------ llvm-svn: 364209
------------------------------------------------------------------------ r360861 | mstorsjo | 2019-05-15 23:49:13 -0700 (Wed, 15 May 2019) | 13 lines [PPC64][libunwind] Fix r2 not properly restored This change makes each unwind step inspect the instruction at the return address and, if needed, read r2 from its saved location and modify the context appropriately. The unwind logic is able to handle both ELFv1 and ELFv2 stacks. Reported by Bug 41050 Patch by Leandro Lupori! Differential Revision: https://reviews.llvm.org/D59694 ------------------------------------------------------------------------ llvm-svn: 364217
------------------------------------------------------------------------ r361114 | mgorny | 2019-05-18 23:05:31 -0700 (Sat, 18 May 2019) | 3 lines [lldb] [lit] Driver/TestConvenienceVariables.test requires Python Differential Revision: https://reviews.llvm.org/D62096 ------------------------------------------------------------------------ llvm-svn: 364257
------------------------------------------------------------------------ r355033 | joerg | 2019-02-27 13:46:01 -0800 (Wed, 27 Feb 2019) | 2 lines Use Secure PLT as default on NetBSD/PowerPC. ------------------------------------------------------------------------ llvm-svn: 364258
------------------------------------------------------------------------ r359809 | rnk | 2019-05-02 10:45:54 -0700 (Thu, 02 May 2019) | 27 lines Use primary template parameter names for variable template debug info Summary: Fixes PR41677 Consider: template <typename LHS, typename RHS> constexpr bool is_same_v = false; template <typename T> constexpr bool is_same_v<T, T> = true; template constexpr bool is_same_v<int, int>; Before this change, when emitting debug info for the `is_same_v<int, int>` global variable, clang would crash because it would try to use the template parameter list from the partial specialization to give parameter names to template arguments. This doesn't work in general, since a partial specialization can have fewer arguments than the primary template. Therefore, always use the primary template. Hypothetically we could try to use the parameter names from the partial specialization when possible, but it's not clear this really helps debugging in practice. Reviewers: JDevlieghere, aprantl, ormris, dblaikie Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61408 ------------------------------------------------------------------------ llvm-svn: 364483
------------------------------------------------------------------------ r354633 | rsmith | 2019-02-21 15:04:35 -0800 (Thu, 21 Feb 2019) | 3 lines Use _Q as MS ABI mangling for char8_t. Thanks to Yuriy Solodkyy for letting us know the mangling here. ------------------------------------------------------------------------ llvm-svn: 364487
------------------------------------------------------------------------ r360861 | mstorsjo | 2019-05-15 23:49:13 -0700 (Wed, 15 May 2019) | 13 lines [PPC64][libunwind] Fix r2 not properly restored This change makes each unwind step inspect the instruction at the return address and, if needed, read r2 from its saved location and modify the context appropriately. The unwind logic is able to handle both ELFv1 and ELFv2 stacks. Reported by Bug 41050 Patch by Leandro Lupori! Differential Revision: https://reviews.llvm.org/D59694 ------------------------------------------------------------------------ llvm-svn: 365539
and PPC64_OPD2 lines to the DEFINE_LIBUNWIND_PRIVATE_FUNCTION() macro, which was removed in r357640: ------------------------------------------------------------------------ r360861 | mstorsjo | 2019-05-15 23:49:13 -0700 (Wed, 15 May 2019) | 13 lines [PPC64][libunwind] Fix r2 not properly restored This change makes each unwind step inspect the instruction at the return address and, if needed, read r2 from its saved location and modify the context appropriately. The unwind logic is able to handle both ELFv1 and ELFv2 stacks. Reported by Bug 41050 Patch by Leandro Lupori! Differential Revision: https://reviews.llvm.org/D59694 ------------------------------------------------------------------------ llvm-svn: 365542
This commit adds a single method to the Context object to parse a textual IR file. This is useful for reading input IR in unit tests. Differential Revision: https://reviews.llvm.org/D66379 llvm-svn: 369210
llvm-svn: 369350
|
This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LLVM Compiler Prerequisites:
#Install CMake version 3.5.1:
LLVM Compiler Installation Steps
Step1:
#download llvm from https://github.com/llvm/llvm-project/releases/download/llvmorg-8.0.1/llvm-8.0.1.src.tar.xz
Step2 : #change present working directory to llvm_source_directory here it is llvm8
Step3: #execute make command in pwd:
Step4 : #after 100% of linking process execute following command in build directory:
step5 : #after installation restart your system!