summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
* MFC r326496:dim2018-02-214-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upgrade our copies of clang, llvm, lldb and libc++ to r319231 from the upstream release_50 branch. This corresponds to 5.0.1 rc2. MFC r326831: Pull in r315334 from upstream lld trunk (by Rafael Espindola): Don't create a dummy __tls_get_addr. We just don't need one with the current setup. We only error on undefined references that are used by some relocation. If we managed to relax all uses of __tls_get_addr, no relocation uses it and we don't produce an error. This is less code and fixes the case were we fail to relax. Before we would produce a broken output, but now we produce an error. Pull in r320390 from upstream lld trunk (by Rafael Espindola): Create reserved symbols early so they can be versioned. This fixes pr35570. We were creating these symbols after parsing version scripts, so they could not be versioned. We cannot move the version script parsing later because we need it for lto. One option is to move both addReservedSymbols and createSyntheticSections earlier. The disadvantage is that some sections created by createSyntheticSections replace other input sections. For example, gdb index replaces .debug_gnu_pubnames, so it wants to run after gc sections so that it can set S->Live to false. What this patch does instead is to move just the ElfHeader creation early. Pull in r320412 from upstream lld trunk (by Rafael Espindola): Handle symbols pointing to output sections. Now that gc sections runs after linker defined symbols are added it can see symbols that point to an OutputSection. Should fix a bot failure. Pull in r320431 from upstream lld trunk (by Peter Collingbourne): ELF: Do not follow relocation edges to output sections during GC. This fixes an assertion error introduced by r320390. Differential Revision: https://reviews.llvm.org/D41095 Together these fix handling of reserved symbols, in particular _end, which is needed to make brk(2) and sbrk(2) work correctly. This unbreaks the emacs ports on amd64, and also appears to unbreak most of world on i386. Differential Revision: https://reviews.freebsd.org/D13466 MFC r326879 (by emaste): lld: Simplify a boolean expression by De Morgan's laws. Cherry-pick lld r315653 by Rui Ueyama: I don't really understand what exactly this expression means, but at least I can mechanically transform it. Obtained from: LLVM r315653 MFC r326897 (by emaste): lld: Slightly simplify code and add comment. Cherry-pick lld r315658 by Rui Ueyama: This is not a mechanical transformation. Even though I believe this patch is correct, I'm not 100% sure if lld with this patch behaves exactly the same way as before on all edge cases. At least all tests still pass. I'm submitting this patch because it took almost a day to understand this function, and I don't want to lose it. This fixes jemalloc assertion failures observed at startup with i386 binaries and an lld-linked libc.so. Reviewed by: dim Obtained from: LLVM r315658 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D13503 MFC r326909: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.1 release (upstream r320880). Relnotes: yes MFC r326957 (by emaste): lld: Don't write preemptible symbol values to the .got. It is not necessary and matches what bfd and gold do. This was a regression from [LLVM] r315658. Obtained from: LLVM r321023 by Rafael Espíndola (cherry picked from commit 1bc68d01849a9c2d056c4cab94b4097bd14c313c)
* Merge clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 release.dim2018-02-21845-22538/+46210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MFC r309126 (by emaste): Correct lld llvm-tblgen dependency file name MFC r309169: Get rid of separate Subversion mergeinfo properties for llvm-dwarfdump and llvm-lto. The mergeinfo confuses Subversion enormously, and these directories will just use the mergeinfo for llvm itself. MFC r312765: Pull in r276136 from upstream llvm trunk (by Wei Mi): Use ValueOffsetPair to enhance value reuse during SCEV expansion. In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult. A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding. In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b. Differential Revision: https://reviews.llvm.org/D21313 This should fix assertion failures when building OpenCV >= 3.1. PR: 215649 MFC r312831: Revert r312765 for now, since it causes assertions when building lang/spidermonkey24. Reported by: antoine PR: 215649 MFC r316511 (by jhb): Add an implementation of __ffssi2() derived from __ffsdi2(). Newer versions of GCC include an __ffssi2() symbol in libgcc and the compiler can emit calls to it in generated code. This is true for at least GCC 6.2 when compiling world for mips and mips64. Reviewed by: jmallett, dim Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D10086 MFC r318601 (by adrian): [libcompiler-rt] add bswapdi2/bswapsi2 This is required for mips gcc 6.3 userland to build/run. Reviewed by: emaste, dim Approved by: emaste Differential Revision: https://reviews.freebsd.org/D10838 MFC r318884 (by emaste): lldb: map TRAP_CAP to a trace trap In the absense of a more specific handler for TRAP_CAP (generated by ENOTCAPABLE or ECAPMODE while in capability mode) treat it as a trace trap. Example usage (testing the bug in PR219173): % proccontrol -m trapcap lldb usr.bin/hexdump/obj/hexdump -- -Cv -s 1 /bin/ls ... (lldb) run Process 12980 launching Process 12980 launched: '.../usr.bin/hexdump/obj/hexdump' (x86_64) Process 12980 stopped * thread #1, stop reason = trace frame #0: 0x0000004b80c65f1a libc.so.7`__sys_lseek + 10 ... In the future we should have LLDB control the trapcap procctl itself (as it does with ASLR), as well as report a specific stop reason. This change eliminates an assertion failure from LLDB for now. MFC r319796: Remove a few unneeded files from libllvm, libclang and liblldb. MFC r319885 (by emaste): lld: ELF: Fix ICF crash on absolute symbol relocations. If two sections contained relocations to absolute symbols with the same value we would crash when trying to access their sections. Add a check that both symbols point to sections before accessing their sections, and treat absolute symbols as equal if their values are equal. Obtained from: LLD commit r292578 MFC r319918: Revert r319796 for now, it can cause undefined references when linking in some circumstances. Reported by: Shawn Webb <shawn.webb@hardenedbsd.org> MFC r319957 (by emaste): lld: Add armelf emulation mode Obtained from: LLD r305375 MFC r321369: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 (trunk r308421). Upstream has branched for the 5.0.0 release, which should be in about a month. Please report bugs and regressions, so we can get them into the release. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. MFC r321420: Add a few more object files to liblldb, which should solve errors when linking the lldb executable in some cases. In particular, when the -ffunction-sections -fdata-sections options are turned off, or ineffective. Reported by: Shawn Webb, Mark Millard MFC r321433: Cleanup stale Options.inc files from the previous libllvm build for clang 4.0.0. Otherwise, these can get included before the two newly generated ones (which are different) for clang 5.0.0. Reported by: Mark Millard MFC r321439 (by bdrewery): Move llvm Options.inc hack from r321433 for NO_CLEAN to lib/clang/libllvm. The files are only ever generated to .OBJDIR, not to WORLDTMP (as a sysroot) and are only ever included from a compilation. So using a beforebuild target here removes the file before the compilation tries to include it. MFC r321664: Pull in r308891 from upstream llvm trunk (by Benjamin Kramer): [CodeGenPrepare] Cut off FindAllMemoryUses if there are too many uses. This avoids excessive compile time. The case I'm looking at is Function.cpp from an old version of LLVM that still had the giant memcmp string matcher in it. Before r308322 this compiled in about 2 minutes, after it, clang takes infinite* time to compile it. With this patch we're at 5 min, which is still bad but this is a pathological case. The cut off at 20 uses was chosen by looking at other cut-offs in LLVM for user scanning. It's probably too high, but does the job and is very unlikely to regress anything. Fixes PR33900. * I'm impatient and aborted after 15 minutes, on the bug report it was killed after 2h. Pull in r308986 from upstream llvm trunk (by Simon Pilgrim): [X86][CGP] Reduce memcmp() expansion to 2 load pairs (PR33914) D35067/rL308322 attempted to support up to 4 load pairs for memcmp inlining which resulted in regressions for some optimized libc memcmp implementations (PR33914). Until we can match these more optimal cases, this patch reduces the memcmp expansion to a maximum of 2 load pairs (which matches what we do for -Os). This patch should be considered for the 5.0.0 release branch as well Differential Revision: https://reviews.llvm.org/D35830 These fix a hang (or extremely long compile time) when building older LLVM ports. Reported by: antoine PR: 219139 MFC r321719: Pull in r309503 from upstream clang trunk (by Richard Smith): PR33902: Invalidate line number cache when adding more text to existing buffer. This led to crashes as the line number cache would report a bogus line number for a line of code, and we'd try to find a nonexistent column within the line when printing diagnostics. This fixes an assertion when building the graphics/champlain port. Reported by: antoine, kwm PR: 219139 MFC r321723: Upgrade our copies of clang, llvm, lld and lldb to r309439 from the upstream release_50 branch. This is just after upstream's 5.0.0-rc1. MFC r322320: Upgrade our copies of clang, llvm and libc++ to r310316 from the upstream release_50 branch. MFC r322326 (by emaste): lldb: Make i386-*-freebsd expression work on JIT path * Enable i386 ABI creation for freebsd * Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap syscall * Unlike linux, the last argument of mmap is actually 64-bit(off_t). This requires us to push an additional word for the higher order bits. * Prior to this change, ktrace dump will show mmap failures due to invalid argument coming from the 6th mmap argument. Submitted by: Karnajit Wangkhem Differential Revision: https://reviews.llvm.org/D34776 MFC r322360 (by emaste): lldb: Report inferior signals as signals, not exceptions, on FreeBSD This is the FreeBSD equivalent of LLVM r238549. This serves 2 purposes: * LLDB should handle inferior process signals SIGSEGV/SIGILL/SIGBUS/ SIGFPE the way it is suppose to be handled. Prior to this fix these signals will neither create a coredump, nor exit from the debugger or work for signal handling scenario. * eInvalidCrashReason need not report "unknown crash reason" if we have a valid si_signo llvm.org/pr23699 Patch by Karnajit Wangkhem Differential Revision: https://reviews.llvm.org/D35223 Submitted by: Karnajit Wangkhem Obtained from: LLVM r310591 MFC r322474 (by emaste): lld: Add `-z muldefs` option. Obtained from: LLVM r310757 MFC r322740: Upgrade our copies of clang, llvm, lld and libc++ to r311219 from the upstream release_50 branch. MFC r322855: Upgrade our copies of clang, llvm, lldb and compiler-rt to r311606 from the upstream release_50 branch. As of this version, lib/msun's trig test should also work correctly again (see bug 220989 for more information). PR: 220989 MFC r323112: Upgrade our copies of clang, llvm, lldb and compiler-rt to r312293 from the upstream release_50 branch. This corresponds to 5.0.0 rc4. As of this version, the cad/stepcode port should now compile in a more reasonable time on i386 (see bug 221836 for more information). PR: 221836 MFC r323245: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 release (upstream r312559). Release notes for llvm, clang and lld will be available here soon: <http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/5.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.html> Relnotes: yes (cherry picked from commit 12cd91cf4c6b96a24427c0de5374916f2808d263)
* MFC r318655:dim2017-05-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in r302416 from upstream llvm trunk (by Martin Storsjö): [ARM] Clear the constant pool cache on explicit .ltorg directives Multiple ldr pseudoinstructions with the same constant value will reuse the same constant pool entry. However, if the constant pool is explicitly flushed with a .ltorg directive, we should not try to reference constants in the previous pool any longer, since they may be out of range. This fixes assembling hand-written assembler source which repeatedly loads the same constant value, across a binary size larger than the pc-relative fixup range for ldr instructions (4096 bytes). Such assembler source already uses explicit .ltorg instructions to emit constant pools with regular intervals. However if we try to reuse constants emitted in earlier pools, they end up out of range. This makes the output of the testcase match what binutils gas does (prior to this patch, it would fail to assemble). Differential Revision: https://reviews.llvm.org/D32847 This should fix "out of range pc-relative fixup value" errors, when compiling certain ARM inline assembly for www/webkit-gtk[23]. Reported by: mmel
* MFC r317458:dim2017-05-063-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in r294458 from upstream llvm trunk (by Sanne Wouda): [Assembler] Enable nicer diagnostics for inline assembly. Fixed test. Summary: Enables source location in diagnostic messages from the backend. This is after parsing, during finalization. This requires the SourceMgr, the inline assembly string buffer, and DiagInfo to still be alive after EmitInlineAsm returns. This patch creates a single SourceMgr for inline assembly inside the AsmPrinter. MCContext gets a pointer to this SourceMgr. Using one SourceMgr per call to EmitInlineAsm would make it difficult for MCContext to figure out in which SourceMgr the SMLoc is located, while a single SourceMgr can figure it out if it has multiple buffers. The Str argument to EmitInlineAsm is copied into a buffer and owned by the inline asm SourceMgr. This ensures that DiagHandlers won't print garbage. (Clang emits a "note: instantiated into assembly here", which refers to this string.) The AsmParser gets destroyed before finalization, which means that the DiagHandlers the AsmParser installs into the SourceMgr will be stale. Restore the saved DiagHandlers. Since now we're using just one SourceMgr for multiple inline asm strings, we need to tell the AsmParser which buffer it needs to parse currently. Hand a buffer id -- returned from SourceMgr:: AddNewSourceBuffer -- to the AsmParser. Reviewers: rnk, grosbach, compnerd, rengolin, rovka, anemet Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29441 This improves error reporting for some inline assembly constructs that clang does not approve of: instead of crashing with a "fatal backend error", it will now show a normal error message, and point out the location of the problematic assembly. Reported by: mmel
* Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release:dim2017-04-02675-20027/+37761
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MFC r309142 (by emaste): Add WITH_LLD_AS_LD build knob If set it installs LLD as /usr/bin/ld. LLD (as of version 3.9) is not capable of linking the world and kernel, but can self-host and link many substantial applications. GNU ld continues to be used for the world and kernel build, regardless of how this knob is set. It is on by default for arm64, and off for all other CPU architectures. Sponsored by: The FreeBSD Foundation MFC r310840: Reapply 310775, now it also builds correctly if lldb is disabled: Move llvm-objdump from CLANG_EXTRAS to installed by default We currently install three tools from binutils 2.17.50: as, ld, and objdump. Work is underway to migrate to a permissively-licensed tool-chain, with one goal being the retirement of binutils 2.17.50. LLVM's llvm-objdump is intended to be compatible with GNU objdump although it is currently missing some options and may have formatting differences. Enable it by default for testing and further investigation. It may later be changed to install as /usr/bin/objdump, it becomes a fully viable replacement. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D8879 MFC r312855 (by emaste): Rename LLD_AS_LD to LLD_IS_LD, for consistency with CLANG_IS_CC Reported by: Dan McGregor <dan.mcgregor usask.ca> MFC r313559 | glebius | 2017-02-10 18:34:48 +0100 (Fri, 10 Feb 2017) | 5 lines Don't check struct rtentry on FreeBSD, it is an internal kernel structure. On other systems it may be API structure for SIOCADDRT/SIOCDELRT. Reviewed by: emaste, dim MFC r314152 (by jkim): Remove an assembler flag, which is redundant since r309124. The upstream took care of it by introducing a macro NO_EXEC_STACK_DIRECTIVE. http://llvm.org/viewvc/llvm-project?rev=273500&view=rev Reviewed by: dim MFC r314564: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 (branches/release_40 296509). The release will follow soon. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. Also note that as of 4.0.0, lld should be able to link the base system on amd64 and aarch64. See the WITH_LLD_IS_LLD setting in src.conf(5). Though please be aware that this is work in progress. Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/lld/docs/ReleaseNotes.html> Thanks to Ed Maste, Jan Beich, Antoine Brodin and Eric Fiselier for their help. Relnotes: yes Exp-run: antoine PR: 215969, 216008 MFC r314708: For now, revert r287232 from upstream llvm trunk (by Daniil Fukalov): [SCEV] limit recursion depth of CompareSCEVComplexity Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time. Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter. Reviewers: sanjoy Subscribers: mzolotukhin, tstellarAMD, llvm-commits Differential Revision: https://reviews.llvm.org/D26389 This commit is the cause of excessive compile times on skein_block.c (and possibly other files) during kernel builds on amd64. We never saw the problematic behavior described in this upstream commit, so for now it is better to revert it. An upstream bug has been filed here: https://bugs.llvm.org/show_bug.cgi?id=32142 Reported by: mjg MFC r314795: Reapply r287232 from upstream llvm trunk (by Daniil Fukalov): [SCEV] limit recursion depth of CompareSCEVComplexity Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time. Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter. Reviewers: sanjoy Subscribers: mzolotukhin, tstellarAMD, llvm-commits Differential Revision: https://reviews.llvm.org/D26389 Pull in r296992 from upstream llvm trunk (by Sanjoy Das): [SCEV] Decrease the recursion threshold for CompareValueComplexity Fixes PR32142. r287232 accidentally increased the recursion threshold for CompareValueComplexity from 2 to 32. This change reverses that change by introducing a separate flag for CompareValueComplexity's threshold. The latter revision fixes the excessive compile times for skein_block.c. MFC r314907 | mmel | 2017-03-08 12:40:27 +0100 (Wed, 08 Mar 2017) | 7 lines Unbreak ARMv6 world. The new compiler_rt library imported with clang 4.0.0 have several fatal issues (non-functional __udivsi3 for example) with ARM specific instrict functions. As temporary workaround, until upstream solve these problems, disable all thumb[1][2] related feature. MFC r315016: Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release. We were already very close to the last release candidate, so this is a pretty minor update. Relnotes: yes MFC r316005: Revert r314907, and pull in r298713 from upstream compiler-rt trunk (by Weiming Zhao): builtins: Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA. Summary: Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation mode (-mthumb, -marm), it reflect's capability of given CPU. Due to this: - use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB - use '.thumb' directive consistently in all affected files - decorate all thumb functions using DEFINE_COMPILERRT_THUMB_FUNCTION() --------- Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 ! Reviewers: weimingz, rengolin, compnerd Subscribers: aemerson, dim Differential Revision: https://reviews.llvm.org/D30938 Discussed with: mmel
* MFC r312832:dim2017-02-032-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in r278160 from upstream llvm trunk (by Wei Mi): Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion". The fix for PR28705 will be committed consecutively. In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult. A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding. In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b. Differential Revision: https://reviews.llvm.org/D21313 Pull in r278161 from upstream llvm trunk (by Wei Mi): Fix the runtime error caused by "Use ValueOffsetPair to enhance value reuse during SCEV expansion". The patch is to fix the bug in PR28705. It was caused by setting wrong return value for SCEVExpander::findExistingExpansion. The return values of findExistingExpansion have different meanings when the function is used in different ways so it is easy to make mistake. The fix creates two new interfaces to replace SCEVExpander::findExistingExpansion, and specifies where each interface is expected to be used. Differential Revision: https://reviews.llvm.org/D22942 Pull in r281439 from upstream llvm trunk (by Wei Mi): Create a getelementptr instead of sub expr for ValueOffsetPair if the value is a pointer. This patch is to fix PR30213. When expanding an expr based on ValueOffsetPair, if the value is of pointer type, we can only create a getelementptr instead of sub expr. Differential Revision: https://reviews.llvm.org/D24088 This should fix assertion failures when building OpenCV >= 3.1, and also allow building lang/spidermonkey24 without any further assertions. PR: 215649
* MFC r309124:dim2016-12-26697-14278/+39950
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0 release, and add lld 3.9.0. Also completely revamp the build system for clang, llvm, lldb and their related tools. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. Release notes for llvm, clang and lld are available here: <http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html> Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan Beich for their help. Relnotes: yes MFC r309147: Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek): [PPC] Set SP after loading data from stack frame, if no red zone is present Follow-up to r280705: Make sure that the SP is only restored after all data is loaded from the stack frame, if there is no red zone. This completes the fix for https://llvm.org/bugs/show_bug.cgi?id=26519. Differential Revision: https://reviews.llvm.org/D24466 Reported by: Mark Millard PR: 214433 MFC r309149: Pull in r283060 from upstream llvm trunk (by Hal Finkel): [PowerPC] Refactor soft-float support, and enable PPC64 soft float This change enables soft-float for PowerPC64, and also makes soft-float disable all vector instruction sets for both 32-bit and 64-bit modes. This latter part is necessary because the PPC backend canonicalizes many Altivec vector types to floating-point types, and so soft-float breaks scalarization support for many operations. Both for embedded targets and for operating-system kernels desiring soft-float support, it seems reasonable that disabling hardware floating-point also disables vector instructions (embedded targets without hardware floating point support are unlikely to have Altivec, etc. and operating system kernels desiring not to use floating-point registers to lower syscall cost are unlikely to want to use vector registers either). If someone needs this to work, we'll need to change the fact that we promote many Altivec operations to act on v4f32. To make it possible to disable Altivec when soft-float is enabled, hardware floating-point support needs to be expressed as a positive feature, like the others, and not a negative feature, because target features cannot have dependencies on the disabling of some other feature. So +soft-float has now become -hard-float. Fixes PR26970. Pull in r283061 from upstream clang trunk (by Hal Finkel): [PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float Enable soft-float support on PPC64, as the backend now supports it. Also, the backend now uses -hard-float instead of +soft-float, so set the target features accordingly. Fixes PR26970. Reported by: Mark Millard PR: 214433 MFC r309212: Add a few missed clang 3.9.0 files to OptionalObsoleteFiles. MFC r309262: Fix packaging for clang, lldb and lld 3.9.0 During the upgrade of clang/llvm etc to 3.9.0 in r309124, the PACKAGE directive in the usr.bin/clang/*.mk files got dropped accidentally. Restore it, with a few minor changes and additions: * Correct license in clang.ucl to NCSA * Add PACKAGE=clang for clang and most of the "ll" tools * Put lldb in its own package * Put lld in its own package Reviewed by: gjb, jmallett Differential Revision: https://reviews.freebsd.org/D8666 MFC r309656: During the bootstrap phase, when building the minimal llvm library on PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream llvm revision r271821 disabled the use of std::call_once, which causes some fallback functions from Atomic.cpp to be used instead. Reported by: Mark Millard PR: 214902 MFC r309835: Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR 70528 (bogus error: constructor required before non-static data member). This should fix buildworld with the external gcc package. Reported by: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/ MFC r310194: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 3.9.1 release. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/3.9.1/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/lld/docs/ReleaseNotes.html> Relnotes: yes
* Pull in r264335 from upstream llvm trunk:dim2016-03-241-0/+1
| | | | | | | | | | | | | | | | | | | Add <atomic> to ThreadPool.h, since std::atomic is used Summary: Apparently, when compiling with gcc 5.3.2 for powerpc64, the order of headers is such that it gets an error about std::atomic<> use in ThreadPool.h, since this header is not included explicitly. See also: https://llvm.org/bugs/show_bug.cgi?id=27058 Fix this by including <atomic>. Patch by Bryan Drewery. Reviewers: chandlerc, joker.eph Subscribers: bdrewery, llvm-commits Differential Revision: http://reviews.llvm.org/D18460
* Convert two llvm source files to native line ending, which was also donedim2016-03-051-59/+59
| | | | upstream. Merging doesn't automatically do this, unfortunately.
* Update llvm and clang to release_38 branch r261369.dim2016-02-213-9/+22
|
* Update llvm, clang and lldb to release_38 branch r260756.dim2016-02-132-5/+1
|
* Update llvm, clang and lldb to release_38 branch r258968.dim2016-01-271-1/+5
|
* Update llvm and clang to release_38 branch r258549.dim2016-01-224-3/+35
|
* Pull in r257902 from upstream llvm trunk, by James Y Knight (this willdim2016-01-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | be merged to the official release_38 branch soon, but we need it ASAP): Stop increasing alignment of externally-visible globals on ELF platforms. With ELF, the alignment of a global variable in a shared library will get copied into an executables linked against it, if the executable even accesss the variable. So, it's not possible to implicitly increase alignment based on access patterns, or you'll break existing binaries. This happened to affect libc++'s std::cout symbol, for example. See thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311 (This is a re-commit of r257719, without the bug reported in PR26144. I've tweaked the code to not assert-fail in enforceKnownAlignment when computeKnownBits doesn't recurse far enough to find the underlying Alloca/GlobalObject value.) Differential Revision: http://reviews.llvm.org/D16145
* Update llvm, clang and lldb to release_38 branch r257836.dim2016-01-163-7/+23
|
* Update llvm, clang and lldb to trunk r257626, and update build glue.dim2016-01-1455-480/+3343
|
* After upstream llvm trunk r252903 and clang trunk r252904, -mcpu=xscaledim2016-01-111-1/+1
| | | | | | was not recognized anymore for arm targets. Fix this by adding the correct sub-arch to the xscale definition in ARMTargetParser.def. This fix (from Andrew Turner) has also been submitted upstream.
* As submitted upstream in a review, avoid using undefined behavior indim2016-01-081-2/+2
| | | | | | | | | | | llvm's LinkAllPasses.h. This caused some of the calls not to be emitted, if the optimization level was -O2 or higher. Conversely, if you used -O1 or lower, calls to e.g. RunningOnValgrind() would be emitted, leading to link failures, because we did not include Valgrind.cpp into libllvmsupport. Therefore, add it unconditionally. Noticed by: ian
* Update llvm to trunk r256945.dim2016-01-0622-112/+417
|
* Update llvm to trunk r256633.dim2015-12-30479-10233/+30158
|
* Upgrade our copies of clang and llvm to 3.7.1 release. This is adim2015-12-252-2/+3
| | | | | | | bugfix-only release, with no new features. Please note that from 3.5.0 onwards, clang and llvm require C++11 support to build; see UPDATING for more information.
* Pull in r248439 from upstream llvm trunk (by Sanjay Patel):dim2015-09-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | set div/rem default values to 'expensive' in TargetTransformInfo's cost model ...because that's what the cost model was intended to do. As discussed in D12882, this fix has a temporary unintended consequence for SimplifyCFG: it causes us to not speculate an fdiv. However, two wrongs make PR24818 right, and two wrongs make PR24343 act right even though it's really still wrong. I intend to correct SimplifyCFG and add to CodeGenPrepare to account for this cost model change and preserve the righteousness for the bug report cases. https://llvm.org/bugs/show_bug.cgi?id=24818 https://llvm.org/bugs/show_bug.cgi?id=24343 Differential Revision: http://reviews.llvm.org/D12882 This fixes the too-eager fdiv hoisting in pow(), which could lead to unexpected floating point exceptions.
* Update llvm, clang and lldb to 3.7.0 release.dim2015-09-066-4/+69
|
* Update llvm/clang to r242221.dim2015-08-1299-1082/+1577
|
* Update llvm/clang to r241361.dim2015-07-05439-2235/+4713
|
* Update llvm/clang to r240225.dim2015-06-23432-1714/+2182
|
* Update Makefiles and other build glue for llvm/clang 3.7.0, as of trunkdim2015-06-10100-1749/+2403
| | | | r239412.
* Merge llvm trunk r238337 from ^/vendor/llvm/dist, resolve conflicts, anddim2015-05-27497-13358/+27405
| | | | preserve our customizations, where necessary.
* Upgrade our copy of clang and llvm to 3.6.1 release.dim2015-05-252-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | This release contains the following cherry-picked revisions from upstream trunk: 226124 226151 226164 226165 226166 226407 226408 226409 226652 226905 226983 227084 227087 227089 227208 227209 227210 227211 227212 227213 227214 227269 227430 227482 227503 227519 227574 227822 227986 227987 227988 227989 227990 228037 228038 228039 228040 228188 228189 228190 228273 228372 228373 228374 228403 228765 228848 228918 229223 229225 229226 229227 229228 229230 229234 229235 229236 229238 229239 229413 229507 229680 229750 229751 229752 229911 230146 230147 230235 230253 230255 230469 230500 230564 230603 230657 230742 230748 230956 231219 231237 231245 231259 231280 231451 231563 231601 231658 231659 231662 231984 231986 232046 232085 232142 232176 232179 232189 232382 232386 232389 232425 232438 232443 232675 232786 232797 232943 232957 233075 233080 233351 233353 233409 233410 233508 233584 233819 233904 234629 234636 234891 234975 234977 235524 235641 235662 235931 236099 236306 236307 Please note that from 3.5.0 onwards, clang and llvm require C++11 support to build; see UPDATING for more information.
* Pull in r230348 from upstream llvm trunk (by Tim Northover):dim2015-03-231-2/+3
| | | | | | | | | | | | | | | | | ARM: treat [N x i32] and [N x i64] as AAPCS composite types The logic is almost there already, with our special homogeneous aggregate handling. Tweaking it like this allows front-ends to emit AAPCS compliant code without ever having to count registers or add discarded padding arguments. Only arrays of i32 and i64 are needed to model AAPCS rules, but I decided to apply the logic to all integer arrays for more consistency. This fixes a possible "Unexpected member type for HA" error when compiling lib/msun/bsdsrc/b_tgamma.c for armv6. Reported by: Jakub Palider <jpa@semihalf.com>
* Merge llvm 3.6.0 final from ^/vendor/llvm/dist, merge clang 3.6.0 finaldim2015-02-251-1/+9
| | | | from ^/vendor/clang/dist, and resolve conflicts.
* Merge llvm 3.6.0rc4 from ^/vendor/llvm/dist, merge clang 3.6.0rc4 fromdim2015-02-193-13/+30
| | | | ^/vendor/clang/dist, resolve conflicts, and update patches.
* Merge llvm 3.6.0rc3 from ^/vendor/llvm/dist, merge clang 3.6.0rc3 fromdim2015-02-143-8/+3
| | | | ^/vendor/clang/dist, resolve conflicts, and update patches README.
* Pull in r227752 from upstream llvm trunk (by Michael Kuperstein):dim2015-02-021-0/+5
| | | | | | | | | | | | | | | | | [X86] Convert esp-relative movs of function arguments to pushes, step 2 This moves the transformation introduced in r223757 into a separate MI pass. This allows it to cover many more cases (not only cases where there must be a reserved call frame), and perform rudimentary call folding. It still doesn't have a heuristic, so it is enabled only for optsize/minsize, with stack alignment <= 8, where it ought to be a fairly clear win. (Re-commit of r227728) Differential Revision: http://reviews.llvm.org/D6789 This helps to get sys/boot/i386/boot2 below the required size again, when optimizing with -Oz.
* Merge llvm 3.6.0rc2 from ^/vendor/llvm/dist, merge clang 3.6.0rc2 fromdim2015-01-316-29/+33
| | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches.
* Merge llvm 3.6.0rc1 from ^/vendor/llvm/dist, merge clang 3.6.0rc1 fromdim2015-01-25419-11195/+19756
| | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches.
* Upgrade our copy of clang and llvm to 3.5.1 release. This is a bugfixdim2015-01-183-21/+50
| | | | | | | | | | | | | | only release, no new features have been added. Please note that this version requires C++11 support to build; see UPDATING for more information. Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.5.1/docs/ReleaseNotes.html> <http://llvm.org/releases/3.5.1/tools/clang/docs/ReleaseNotes.html> MFC after: 1 month X-MFC-With: 276479
* Pull in r214284 from upstream llvm trunk (by Hal Finkel):dim2014-12-254-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [PowerPC] Add JMP_SLOT relocation definitions This will be required by upcoming patches for LLDB support. Patch by Justin Hibbits! Pull in r221510 from upstream llvm trunk (by Justin Hibbits): Add Position-independent Code model Module API. Summary: This makes PIC levels a Module flag attribute, which can be queried by the backend. The flag is named `PIC Level`, and can have a value of: 0 - Backend-default 1 - Small-model (-fpic) 2 - Large-model (-fPIC) These match the `-pic-level' command line argument for clang, and the value of the preprocessor macro `__PIC__'. Test Plan: New flags tests specific for the 'PIC Level' module flag. Tests to be added as part of a future commit for PowerPC, which will use this new API. Reviewers: rafael, echristo Reviewed By: rafael, echristo Subscribers: rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D5882 Pull in r221791 from upstream llvm trunk (by Justin Hibbits): Add support for small-model PIC for PowerPC. Summary: Large-model was added first. With the addition of support for multiple PIC models in LLVM, now add small-model PIC for 32-bit PowerPC, SysV4 ABI. This generates more optimal code, for shared libraries with less than about 16380 data objects. Test Plan: Test cases added or updated Reviewers: joerg, hfinkel Reviewed By: hfinkel Subscribers: jholewinski, mcrosier, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D5399 Together, these changes implement small-model PIC support for PowerPC. Thanks to Justin Hibbits and Roman Divacky for their assistance in getting this working.
* Pull in r223147, r223255 and r223390 from upstream llvm trunk (by Romandim2014-12-091-0/+9
| | | | | | | | | | | | | | | Divacky): Introduce CPUStringIsValid() into MCSubtargetInfo and use it for ARM .cpu parsing. Previously .cpu directive in ARM assembler didnt switch to the new CPU and therefore acted as a nop. This implemented real action for .cpu and eg. allows to assembler FreeBSD kernel with -integrated-as. Change the name to be in style. Add a FIXME as requested by Renato Golin.
* Pull in r216571 from upstream llvm trunk (by Zachary Turner):dim2014-11-261-2/+3
| | | | | | | | | | | | Fix some semantic usability issues with DynamicLibrary. This patch allows invalid DynamicLibrary instances to be constructed, and fixes the const-correctness of the isValid() method. No functional change. This is needed for supporting the upgrade to a newer LLDB snapshot.
* Pull in r215352 from upstream llvm trunk (by Tim Northover):dim2014-11-261-1/+14
| | | | | | | | | | | AArch64: add support for dynamic-loader relocations LLD needs them, and it's good to be able to print them properly when our object dumpers encounter them. Patch by Daniel Stewart. This is needed for supporting the upgrade to a newer LLDB snapshot.
* Merge llvm 3.5.0 release from ^/vendor/llvm/dist, resolve conflicts, anddim2014-11-24514-16200/+33404
| | | | preserve our customizations, where necessary.
* Pull in r221709 from upstream llvm trunk (by Frédéric Riss):dim2014-11-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Totally forget deallocated SDNodes in SDDbgInfo. What would happen before that commit is that the SDDbgValues associated with a deallocated SDNode would be marked Invalidated, but SDDbgInfo would keep a map entry keyed by the SDNode pointer pointing to this list of invalidated SDDbgNodes. As the memory gets reused, the list might get wrongly associated with another new SDNode. As the SDDbgValues are cloned when they are transfered, this can lead to an exponential number of SDDbgValues being produced during DAGCombine like in http://llvm.org/bugs/show_bug.cgi?id=20893 Note that the previous behavior wasn't really buggy as the invalidation made sure that the SDDbgValues won't be used. This commit can be considered a memory optimization and as such is really hard to validate in a unit-test. This should fix abnormally large memory usage and resulting OOM crashes when compiling certain ports with debug information. Reported by: Dmitry Marakasov <amdmi3@amdmi3.ru> Upstream PRs: http://llvm.org/PR19031 http://llvm.org/PR20893 MFC after: 1 week
* Backport r197824, r213427 and r213960 from LLVM trunk:rdivacky2014-08-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | r197824 | rdivacky | 2013-12-20 19:08:54 +0100 (Fri, 20 Dec 2013) | 2 lines Implement initial-exec TLS for PPC32. r213427 | hfinkel | 2014-07-19 01:29:49 +0200 (Sat, 19 Jul 2014) | 7 lines [PowerPC] 32-bit ELF PIC support This adds initial support for PPC32 ELF PIC (Position Independent Code; the -fPIC variety), thus rectifying a long-standing deficiency in the PowerPC backend. Patch by Justin Hibbits! r213960 | hfinkel | 2014-07-25 19:47:22 +0200 (Fri, 25 Jul 2014) | 3 lines [PowerPC] Support TLS on PPC32/ELF Patch by Justin Hibbits! Reviewed by: jhibbits Approved by: dim
* Upgrade our copy of llvm/clang to 3.4.1 release. This release containsdim2014-05-122-33/+46
| | | | | | | | | | | | | | | mostly fixes, for the following upstream bugs: http://llvm.org/PR16365 http://llvm.org/PR17473 http://llvm.org/PR18000 http://llvm.org/PR18068 http://llvm.org/PR18102 http://llvm.org/PR18165 http://llvm.org/PR18260 http://llvm.org/PR18290 http://llvm.org/PR18316 http://llvm.org/PR18460 http://llvm.org/PR18473 http://llvm.org/PR18515 http://llvm.org/PR18526 http://llvm.org/PR18600 http://llvm.org/PR18762 http://llvm.org/PR18773 http://llvm.org/PR18860 http://llvm.org/PR18994 http://llvm.org/PR19007 http://llvm.org/PR19010 http://llvm.org/PR19033 http://llvm.org/PR19059 http://llvm.org/PR19144 http://llvm.org/PR19326 MFC after: 2 weeks
* Merge LLVM r202188:emaste2014-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | Debug info: Support variadic functions. Variadic functions have an unspecified parameter tag after the last argument. In IR this is represented as an unspecified parameter in the subroutine type. Paired commit with CFE r202185. rdar://problem/13690847 This re-applies r202184 + a bugfix in DwarfDebug's argument handling. This merge includes a change to use the LLVM 3.4 API in lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp: DwarfUnit -> CompileUnit Sponsored by: DARPA, AFRL
* Pull in r196939 from upstream llvm trunk (by Reid Kleckner):dim2014-03-183-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reland "Fix miscompile of MS inline assembly with stack realignment" This re-lands commit r196876, which was reverted in r196879. The tests have been fixed to pass on platforms with a stack alignment larger than 4. Update to clang side tests will land shortly. Pull in r196986 from upstream llvm trunk (by Reid Kleckner): Revert the backend fatal error from r196939 The combination of inline asm, stack realignment, and dynamic allocas turns out to be too common to reject out of hand. ASan inserts empy inline asm fragments and uses aligned allocas. Compiling any trivial function containing a dynamic alloca with ASan is enough to trigger the check. XFAIL the test cases that would be miscompiled and add one that uses the relevant functionality. Pull in r202930 from upstream llvm trunk (by Hans Wennborg): Check for dynamic allocas and inline asm that clobbers sp before building selection dag (PR19012) In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo to make sure that ESI isn't used as a base pointer register before we choose to emit rep movs (which clobbers esi). The problem is that MachineFrameInfo wouldn't know about dynamic allocas or inline asm that clobbers the stack pointer until SelectionDAGBuilder has encountered them. This patch fixes the problem by checking for such things when building the FunctionLoweringInfo. Differential Revision: http://llvm-reviews.chandlerc.com/D2954 Together, these commits fix the problem encountered in the devel/emacs port on the i386 architecture, where a combination of stack realignment, alloca() and memcpy() could incidentally clobber the %esi register, leading to segfaults in the temacs build-time utility. See also: http://llvm.org/PR18171 and http://llvm.org/PR19012 Reported by: ashish PR: ports/183064 MFC after: 1 week
* Merge from head up to r262611.dim2014-02-281-0/+1
|\
| * Pull in r196874 from upstream llvm trunk:dim2014-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a crash that occurs when PWD is invalid. MCJIT needs to be able to run in hostile environments, even when PWD is invalid. There's no need to crash MCJIT in this case. The obvious fix is to simply leave MCContext's CompilationDir empty when PWD can't be determined. This way, MCJIT clients, and other clients that link with LLVM don't need a valid working directory. If we do want to guarantee valid CompilationDir, that should be done only for clients of getCompilationDir(). This is as simple as checking for an empty string. The only current use of getCompilationDir is EmitGenDwarfInfo, which won't conceivably run with an invalid working dir. However, in the purely hypothetically and untestable case that this happens, the AT_comp_dir will be omitted from the compilation_unit DIE. This should help fix assertions occurring with ports-mgmt/tinderbox, when it is using jails, and sometimes invalidates clang's current working directory. Reported by: decke MFC after: 2 weeks X-MFC-With: r261991
* | Import a whole bunch of llvm trunk commits to enable self-hosting clangdim2014-02-203-1/+101
|/ | | | | | | | | | | | | | 3.4 on Sparc64 (commit descriptions left out for brevity): r196755 r198028 r198029 r198030 r198145 r198149 r198157 r198565 r199186 r199187 r198280 r198281 r198286 r198480 r198484 r198533 r198567 r198580 r198591 r198592 r198658 r198681 r198738 r198739 r198740 r198893 r198909 r198910 r199014 r199024 r199028 r199031 r199033 r199061 r199775 r199781 r199786 r199940 r199974 r199975 r199977 r200103 r200104 r200112 r200130 r200131 r200141 r200282 r200368 r200373 r200376 r200509 r200617 r200960 r200961 r200962 r200963 r200965 Submitted by: rdivacky
OpenPOWER on IntegriCloud