summaryrefslogtreecommitdiffstats
path: root/lib/clang
Commit message (Collapse)AuthorAgeFilesLines
* Merge clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 release.dim2017-09-2616-151/+390
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MFC r319473:dim2017-06-081-5/+6
| | | | | | | | | | | | | | | | | | | | For arm targets, place ABI at the end of the target triple For some reason, we have been inserting the ABI specification into the middle of the target triple, when building LLVM, like so: armv6-gnueabi-freebsd12.0 This is the wrong way around. LLVM even auto-canonicalizes it to: armv6--freebsd12.0-gnueabi Let's do this the right way in llvm.build.mk instead. While here, define a proper VENDOR macro which can be overridden easily. Approved by: re (gjb) Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D10846
* Update stable/11 from 11.0-STABLE to 11.1-PRERELEASE, marking thegjb2017-05-191-1/+1
| | | | | | | | | | | official start of the code slush. Set the default mdoc(7) version to 11.1, and update the clang(1) TARGET_TRIPLE to reflect 11.1. While here, add missing FreeBSD major versions to mdoc(7). Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
* MFC r317214:dim2017-04-292-1/+5
| | | | | | | | | | | | Turn off llvm/clang's ENABLE_BACKTRACES setting, since it never worked properly anyway. (Upstream has reorganized this somewhat in the mean time, but for proper backtraces we would need llvm-symbolizer in base.) MFC r317215: Add function and data sections when building llvm, clang, lld and lldb, and allow the linker to garbage collect them. This shaves off up to a few MB from the final executables.
* Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release:dim2017-04-0213-333/+305
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 r309124:dim2016-12-26433-7444/+2889
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MFC r304530:dim2016-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in r265122 from upstream llvm trunk (by James Molloy): Fix for pr24346: arm asm label calculation error in sub Some ARM instructions encode 32-bit immediates as a 8-bit integer (0-255) and a 4-bit rotation (0-30, even) in its least significant 12 bits. The original fixup, FK_Data_4, patches the instruction by the value bit-to-bit, regardless of the encoding. For example, assuming the label L1 and L2 are 0x0 and 0x104 respectively, the following instruction: add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260 would be assembled to the following, which adds 1 to r0, instead of 260: e2800104 add r0, r0, #4, 2 ; equivalently 1 The new fixup kind fixup_arm_mod_imm takes care of the encoding: e2800f41 add r0, r0, #260 Patch by Ting-Yuan Huang! This fixes label calculation for ARM assembly, and is needed to enable ARM assembly sources for OpenSSL. Requested by: jkim
* MFC r304319:dim2016-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Pull in r262772 from upstream clang trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17682 Pull in r262782 from upstream llvm trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17683 This ensures clang does not emit AVX instructions for CPUTYPE=btver1. Reported by: Michel Depeige <demik+freebsd@lostwave.net> PR: 211864
* Similar to r256297, disable assertions in llvm and clang for thedim2016-08-162-2/+2
| | | | | | stable/11 branch. This reduces the size of the clang executable, and improves its performance. Also bump FREEBSD_CC_VERSION to make some version number room for the branch.
* Add clang-format under WITH_CLANG_EXTRAS.bdrewery2016-06-175-1/+72
| | | | | | | Reviewed by: dim Approved by: re (gjb) Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D6856
* For clang, move the definition of FREEBSD_CC_VERSION into its own headerdim2016-06-033-2/+6
| | | | | | | | | | file, lib/clang/freebsd_cc_version.h, instead of reusing Version.inc. The header is only included from one .cpp file in the clang tree. This minimizes the number of .cpp files that need to be rebuilt if the version is bumped. Discussed with: bdrewery
* Pull in r271548 from upstream llvm trunk (by me):dim2016-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Only attempt to detect AVG if SSE2 is available Summary: In PR29973 Sanjay Patel reported an assertion failure when a certain loop was optimized, for a target without SSE2 support. It turned out this was because of the AVG pattern detection introduced in rL253952. Prevent the assertion failure by bailing out early in `detectAVGPattern()`, if the target does not support SSE2. Also add a minimized test case. Reviewers: congh, eli.friedman, spatel Subscribers: emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D20905 This should fix assertion failures ("Requires at least SSE2!") when building the games/0ad port with CPUTYPE=pentium3. Reported by: madpilot
* Bump __FreeBSD_cc_version after r300974.dim2016-05-301-1/+1
|
* Add FREEBSD_CC_VERSION which will be used to define __FreeBSD_cc_version.bdrewery2016-05-211-0/+2
| | | | | | | | | | | | The WITH_SYSTEM_COMPILER build option will rely on this value to determine what __FreeBSD_cc_version the source tree will produce. This value will be compared against the /usr/bin/cc value to determine if a new compiler is needed. Start with 1100002 which is 1 more than than the value we've had since 3.8.0 to ensure that all changes since then are present. Reviewed by: dim Sponsored by: EMC / Isilon Storage Division
* Make armv6 hard float abi by default. Kill armv6hf.imp2016-05-181-4/+7
| | | | | | | Allow CPUTYPE=soft to build the current soft-float abi libraries. Add UPDATING entry to announce this. Approved by: re@ (gjb)
* Limit Options.inc generation to desired targetsemaste2016-05-051-2/+3
| | | | | | | | | | | | | | As mentioned in the Makefile there's an "atrocious" hack to generate a different version of Options.inc.h, depending on the library being built. Remove the catch-all else case and limit it to specific libraries, so that we don't accidentally use the Options.inc.h from clangdriver if a future libary also uses Options.inc.h. Reviewed by: dim Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D6209
* Implement (ACFLAGS|CFLAGS|CXXFLAGS).SRC globally.bdrewery2016-03-261-1/+0
| | | | Sponsored by: EMC / Isilon Storage Division
* Use the new bmake .dinclude feature to make these safe.bdrewery2016-03-111-5/+9
| | | | | | | | At least FAST_DEPEND won't even run 'make depend', so the code was potentially broken with FAST_DEPEND anyhow. The .dinclude directive will ignore missing files rather than make them be fatal. Sponsored by: EMC / Isilon Storage Division
* DIRDEPS_BUILD: Update clang dependencies after r296417.bdrewery2016-03-0878-125/+166
| | | | Sponsored by: EMC / Isilon Storage Division
* Update llvm and clang to 3.8.0 release.dim2016-03-031-1/+1
|
* Update llvm and clang to release_38 branch r261684.dim2016-02-241-1/+1
|
* Merge ^/head r295902 through r296006.dim2016-02-2495-7336/+0
|\
| * DIRDEPS_BUILD: Regenerate without local dependencies.bdrewery2016-02-24101-7406/+0
| | | | | | | | | | | | | | | | These are no longer needed after the recent 'beforebuild: depend' changes and hooking DIRDEPS_BUILD into a subset of FAST_DEPEND which supports skipping 'make depend'. Sponsored by: EMC / Isilon Storage Division
| * FAST_DEPEND: Always run depend via beforebuild which removes many hacks.bdrewery2016-02-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will generate dependencies rather than depending on the previous behavior of depending on the guessed OBJS: *.h dependecies or a user running 'make depend'. Experimentation showed that depending only on headers was not enough and prone to .ORDER errors. Downstream users may also have added dependencies into beforedepend or afterdepend targets. The safest way to ensure dependencies are generated before build is to run 'make depend' beforehand rather than just depending on DPSRCS+SRCS. Note that the OBJS_DEPEND_GUESS mechanism (a.k.a .if !exists(.depend) then foo.o: *.h) is still useful as it improves incremental builds with missing .depend.* files and allows 'make foo.o' to usually work, while this 'beforebuild: depend' ensures that the build will always find all dependencies. The 'make foo.o' case has no means of a 'beforebuild' hook. This also removes several hacks in the DIRDEPS_BUILD: - NO_INSTALL_INCLUDES is no longer needed as it mostly was to work around .ORDER problems with building the needed headers early. - DIRDEPS_BUILD: It is no longer necesarry to track "local dependencies" in Makefile.depend. These were only in Makefile.depend for 'clean builds' since nothing would generate the files due to skipping 'make depend' and early dependency bugs that have been fixed, such as adding headers into SRCS for the OBJS_DEPEND_GUESS mechanism. Normally if a .depend file does not exist then a dependency is added by bsd.lib.mk/bsd.prog.mk from OBJS: *.h. However, meta.autodep.mk creates a .depend file from created meta files and inserts that into Makefile.depend. It also only tracks *.[ch] files though which can miss some dependencies that are hooked into 'make depend'. This .depend that is created then breaks incremental builds due to the !exists(.depend) checks for OBJS_DEPEND_GUESS. The goal was to skip 'make depend' yet it only really works the first time. After that files are not generated as expected, which r288966 tried to address but was using buildfiles: rather than beforebuild: and was reverted in r291725. As noted previously, depending only on headers in beforebuild: would create .ORDER errors in some cases. meta.autodep.mk is still used to generate Makefile.depend though via: gendirdeps: Makefile.depend .END: gendirdeps This commit allows removing all of the "local dependencies" in Makefile.depend which cuts down on churn and removes some of the arch-dependent Makefile.depend files. The "local dependencies" were also problematic for bootstrapping. Sponsored by: EMC / Isilon Storage Division
* | Update llvm and clang to release_38 branch r261369.dim2016-02-211-1/+1
| |
* | Merge ^/head r295601 through r295844.dim2016-02-217-0/+114
|\ \ | |/
| * DIRDEPS_BUILD: Hookup CLANG_EXTRAS.bdrewery2016-02-167-0/+114
| | | | | | | | Sponsored by: EMC / Isilon Storage Division
* | Update llvm, clang and lldb to release_38 branch r260756.dim2016-02-131-1/+1
| |
* | Update llvm, clang and lldb to release_38 branch r258968.dim2016-01-271-1/+1
| |
* | Undo r294499 for now (which disabled -mlong-calls), so arm builds candim2016-01-231-2/+1
| | | | | | | | succeed again.
* | Update llvm and clang to release_38 branch r258549.dim2016-01-221-1/+1
| |
* | Merge ^/head r294169 through r294598.dim2016-01-221-1/+2
|\ \ | |/
| * Disable -mlong-calls for the clang libraries for now, it increases theandrew2016-01-211-1/+2
| | | | | | | | size of the clang binary for people with a crt1.o from before r293832.
* | Update llvm/clang build glue.dim2016-01-164-6/+7
| |
* | Merge ^/head r293850 through r294089.dim2016-01-151-0/+4
|\ \ | |/
| * Set -mlong-calls where needed to get a static clang and lldb 3.8.0andrew2016-01-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | linking. These are too large for a branch instruction to branch from an earlier point in the code to somewhere later. This will also allow these to be build with Thumb-2 when we get this infrastructure. Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D4855
* | Update llvm, clang and lldb to trunk r257626, and update build glue.dim2016-01-143-3/+8
| |
* | 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 library dependencies.dim2016-01-061-0/+1
| |
* | Update llvm/clang svn revision.dim2016-01-061-1/+1
| |
* | Add new pkuintrin.h intrinsics header.dim2016-01-061-0/+1
| |
* | Update build infrastructure for LLDB 3.8emaste2016-01-0419-50/+159
| |
* | Build Valgrind.cpp for LLDB, not only CLANG_EXTRASemaste2016-01-031-2/+2
| | | | | | | | It's required as of LLDB 3.8.
* | Next part of updating llvm/clang build glue: getting thedim2015-12-3111-22/+37
| | | | | | | | WITH_CLANG_EXTRAS tools built.
* | First part of updating llvm/clang build glue: getting llvm-tblgen,dim2015-12-3168-123/+194
| | | | | | | | clang-tblgen and clang itself built.
* | Update various build glue files for the new llvm/clang version number.dim2015-12-301-2/+7
| |
* | Update clang's Version.inc file, and regenerate various generateddim2015-12-305-133/+170
|/ | | | | configuration headers (these used to be generated by autoconf, but upstream has deprecated autoconf in favor of CMake).
* Upgrade our copies of clang and llvm to 3.7.1 release. This is adim2015-12-255-12/+12
| | | | | | | 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.
* META MODE: Update dependencies with 'the-lot' and add missing directories.bdrewery2015-12-0166-1399/+442
| | | | | | | | | | | | | | This is not properly respecting WITHOUT or ARCH dependencies in target/. Doing so requires a massive effort to rework targets/ to do so. A better approach will be to either include the SUBDIR Makefiles directly and map to DIRDEPS or just dynamically lookup the SUBDIR. These lose the benefit of having a userland/lib, userland/libexec, etc, though and results in a massive package. The current implementation of targets/ is very unmaintainable. Currently rescue/rescue and sys/modules are still not connected. Sponsored by: EMC / Isilon Storage Division
* META MODE: Rework [bootstrapped] tools PATH support.bdrewery2015-12-011-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Support more of the toolchain from TOOLSDIR. - This also improves 'make bootstrap-tools' to pass, for example, AS=/usr/bin/as to Makefile.inc1, which will tell cross-tools to use external toolchain support and avoid building things we won't be using in the build. - Always set the PATH to contain the staged TOOLSDIR directories when not building the bootstrap targets. The previous version was only setting this at MAKE.LEVEL==0 and if the TOOLSDIR existed. Both of these prevented using staged tools that were built during the build though as DIRDEPS with .host dependencies, such as the fix for needing usr.bin/localedef.host in r291311. This is not a common tool so we must build and use it during the build, and need to be prepared to change PATH as soon as it appears. This should also fix the issue of host dependencies disappearing from Makefile.depend and then reappearing due to the start of the fresh build not having the directory yet, resulting in the tools that were built not actually being used. - Only use LEGACY_TOOLS while building in Makefile.inc1. After r291317 and r291546 there is no need to add LEGACY_TOOLS into the PATH for the pseudo/targets/toolchain build. - Because the pseudo/targets/toolchain will now build its own [clang-]tblgen, the special logic in clang.build.mk is no longer needed. - LEGACY_TOOLS is no longer used outside of targets/pseudo/bootstrap-tools so is no longer passed into the environment in its build. Sponsored by: EMC / Isilon Storage Division
OpenPOWER on IntegriCloud