summaryrefslogtreecommitdiff
path: root/contrib/llvm/tools/clang/lib/Parse/ParseAST.cpp
Commit message (Collapse)AuthorAgeFilesLines
* MFC r355940:Dimitry Andric2020-05-051-189/+0
| | | | | | | | | | | | | | | Move all sources from the llvm project into contrib/llvm-project. This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next. Notes: svn path=/stable/11/; revision=360660
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-05-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 9.0.0 final release r372316. (NOTE: This does not yet consolidate all the llvm project sources under contrib/llvm-project (e.g., MFC r355940), due to Subversion limitations. It will be done in a follow-up MFC.) MFC r348610 (by emaste): build llvm-ar and llvm-nm with Clang (promote out of CLANG_EXTRAS) To facilitate experimentation with LTO we require an ar that supports LLVM IR, and to a lesser degree also an nm. As a first step always install llvm-ar and llvm-nm. Sponsored by: The FreeBSD Foundation MFC r350453 (by asomers): Add a CXXWARNFLAGS variable Some warning flags are valid for C++ but not C. GCC 8 complains if you pass such flags when building a C file. Using a separate variable for these flags allows building both C and C++ files in the same directory (such as the fusefs tests) under GCC. Reviewed by: cem, emaste Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21116 MFC r350467 (by luporl): [PPC64] Backport fix for missing IRELATIVE relocations This is a backport of LLVM commit 8331f61a51a7a0a1efbf5ed398e181593023d151, llvm-svn: 353981: ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an IRELATIVE where possible. This is needed in order to make ifuncs work correctly on PPC64. It fixes an issue with lld, in which it would skip emitting necessary IRELATIVE relocations. Without this change, indirect calls to ifuncs would result in a segmentation fault, in static binaries or when defined in the main binary (outside shared libraries). This change also reverts the local "Preserve relocations against ifuncs when -zifunc-noplt" commit and replaces it by its upstream version, as part of the merge. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D21102 MFC r351662 (by emaste): lldb: shorten thread names to make logs easier to follow lldb prepends the thread name to log entries, and the existing thread name for the FreeBSD ProcessMonitor thread was longer than the kernel's supported thread name length, and so was truncated. This made logs hard to read, as the truncated thread name ran into the log message. Shorten "lldb.process.freebsd.operation" to just "freebsd.op" so that logs are more readable. (Upstreaming to lldb still to be done). MFC r352095 (by emaste): compiler-rt: use more __sanitizer_time_t on FreeBSD A few structs were using long for time_t members. Obtained from: LLVM r370755 MFC r352096 (by emaste): compiler-rt: use 64-bit time_t for all FreeBSD archs except i386 Obtained from: LLVM r370756 MFC r352167 (by imp): Remove dir empty since r276851 MFC r352168 (by imp): Remove dirs empty since r280031 MFC r352169 (by imp): Remove dir empty since r314564 MFC r352170 (by imp): Remove dir empty since r327952 MFC r352171 (by imp): Remove dirs (and their now-empty parents) empty since r344779 MFC r352792 (by emaste): compiler-rt: correct RISC-V struct_kernel_stat64_sz The value of struct_kernel_stat64_sz introduced by review D5021 for RISC-V was incorrect. Also add a __riscv_xlen == 64 conditional as the 32-bit ABI is not yet finalized. Submitted by: Luís Marques Differential Revision: https://reviews.freebsd.org/D21684 MFC r353018 (by kevans): clang: use -mxgot for 32-bit mips Various bits in usr.bin/clang/* will fail to compile without -mxgot due to truncated relocations. -mxgot entails a speed penalty, but I suspect we don't care as much about compiler performance in 32-bit mips land. Reviewed by: arichardson Differential Revision: https://reviews.freebsd.org/D21698 MFC r353358: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316. Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC r353363: Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be checked before access or destruction" when launching executables, while we sort this out with upstream. Reported by: jbeich PR: 241137 MFC r353415: Revert r353363 in preparation for applying upstream fix: Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be checked before access or destruction" when launching executables, while we sort this out with upstream. PR: 241137 MFC r353416: Pull in r374444 from upstream lldb trunk (by me): Fix process launch failure on FreeBSD after r365761 Summary: After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS` enabled, launching any process on FreeBSD crashes lldb with: ``` Expected<T> must be checked before access or destruction. Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed). ``` This is because `m_operation_thread` and `m_monitor_thread` were wrapped in `llvm::Expected<>`, but this requires the objects to be correctly initialized before accessing them. To fix the crashes, use `llvm::Optional<>` for the members (as indicated by labath), and use local variables to store the return values of `LaunchThread` and `StartMonitoringChildProcess`. Then, only assign to the member variables after checking if the return values indicated success. Reviewers: devnexen, emaste, MaskRay, mgorny Reviewed By: devnexen Subscribers: jfb, labath, krytarowski, lldb-commits Differential Revision: https://reviews.llvm.org/D68723 PR: 241137 MFC r353579 (by jhb): Use __FreeBSD_version to determine if gets() has been removed. GCC compilers set __FreeBSD__ statically to a build-time determined targeted version (which in ports always matches the build host's version). This means that when building any version (12 or 13, etc.) of riscv or some other architecture via GCC on a 12.x host, __FreeBSD__ will always be set to 12. As a result, __FreeBSD__ cannot be used to reliably detect the target FreeBSD version being built. Instead, __FreeBSD_version from either <sys/param.h> (in the kernel) or <osreldate.h> (in userland) should be used. This changes the gets() test in libc++ to use __FreeBSD_version from <osreldate.h>. Reported by: jenkins (riscv64 and amd64-gcc) Reviewed by: dim, imp Differential Revision: https://reviews.freebsd.org/D22034 MFC r353711 (by mhorne): Fix build of LLVM RISC-V backend Reviewed by: dim MFC with: r353358 Differential Revision: https://reviews.freebsd.org/D21963 MFC r353738: Pull in r372651 from upstream lld trunk (by Simon Atanasyan): [mips] Support elf32btsmipn32_fbsd / elf32ltsmipn32_fbsd emulations Patch by Kyle Evans. Requested by: kevans MFC r353739: Pull in r374154 from upstream clang trunk (by Simon Atanasyan): [mips] Set default float ABI to "soft" on FreeBSD Initial patch by Kyle Evans. Fix PR43596 Requested by: kevans MFC r353936: Bump clang's default target CPU for the i386 architecture (aka "x86") to i686, as per the discussion on the freebsd-arch mailing list. Earlier in r352030, I had already bumped it to i586, to work around missing atomic 64 bit functions for the i386 architecture. Relnotes: yes MFC r354097: Pull in r372186 from upstream llvm trunk (by Eli Friedman): [ARM] VFPv2 only supports 16 D registers. r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers. In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions. This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32". Differential Revision: https://reviews.llvm.org/D67375 Pull in r372187 from upstream clang trunk (by Eli Friedman): [ARM] Update clang for removal of vfp2d16 and vfp2d16sp Matching fix for https://reviews.llvm.org/D67375 (r372186). Differential Revision: https://reviews.llvm.org/D67467 This should fix clang generating invalid opcodes for floating point operations on armv6. Requested by: mmel MFC r354146: Pull in r373338 from upstream llvm trunk (by Simon Pilgrim): Revert rL349624 : Let TableGen write output only if it changed, instead of doing so in cmake, attempt 2 Differential Revision: https://reviews.llvm.org/D55842 ----------------- As discussed on PR43385 this is causing Visual Studio msbuilds to perpetually rebuild all tablegen generated files Pull in r373664 from upstream llvm trunk (by Nico Weber): Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. This should fix the scenario where an incremental build from before r353358 (the clang 9.0.0 upgrade) to r353358 or later fails to update the timestamp of the generated lib/clang/headers/arm_fp16.h header. After such a build, installing world from read-only source and object directories would attempt to generate the header again, leading to "clang-tblgen: error opening arm_fp16.h.d:Read-only file system". Reported by: avg, np PR: 241402 MFC r354339: Merge commit 97e362607 from llvm git (by Nemanja Ivanovic): [PowerPC] Do not emit HW loop if the body contains calls to lrint/lround These two intrinsics are lowered to calls so should prevent the formation of CTR loops. In a subsequent patch, we will handle all currently known intrinsics and prevent the formation of HW loops if any unknown intrinsics are encountered. Differential revision: https://reviews.llvm.org/D68841 This should fix an "invalid CRT loop" assertion when building the www/node port for powerpc64. Requested by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br> MFC r354347 (by cem): Fix llvm-libunwind userspace build on ARM GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s, on ARM. As part of this, convert libgcc_s from a direct Version.map to one constructed from component Symbol.map files. This allows the ARM-specific Symbol.map to be included only on ARM. Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match non-ARM definitions and ARM-specific expectations in libcxxrt / libcompiler_rt. No functional change intended for non-ARM architectures. This commit does not actually flip the switch for ARM defaults from libgcc to llvm-libunwind, but makes it possible (to compile, anyway). MFC r354418 (by cem): clang: Enable unwind tables on !amd64 There doesn't seem to be much sense in defaulting "on" unwind tables on amd64 and not on other arches. It causes surprising differences between platforms, such as the PR below. Prior to this change, FreeBSD inherited the default implementation of the method from the Gnu.h Generic_Elf => Generic_GCC parent class, which returned true only for amd64 targets. Override that and opt on always, similar to, e.g., NetBSD. PR: 241562 Reported by: lwhsu Reviewed by: dim Discussed with: emaste Relnotes: yes Differential Revision: https://reviews.freebsd.org/D22252 MFC r354429: Merge commit 8e34dd941 from llvm git (by Sanjay Patel): [x86] avoid crashing when splitting AVX stores with non-simple type (PR43916) The store splitting transform was assuming a simple type (MVT), but that's not necessarily the case as shown in the test. This should fix 'Assertion failed: (isSimple() && "Expected a SimpleValueType!")' when building the security/openssl111 port targeting a CPU that supports AVX, but not AVX2, such as sandybridge. PR: 241747 MFC r354469: Merge commit f596f4507 from llvm git (by Sam Elliott): [RISCV] Add Custom Parser for Atomic Memory Operands Summary: GCC Accepts both (reg) and 0(reg) for atomic instruction memory operands. These instructions do not allow for an offset in their encoding, so in the latter case, the 0 is silently dropped. Due to how we have structured the RISCVAsmParser, the easiest way to add support for parsing this offset is to add a custom AsmOperand and parser. This parser drops all the parens, and just keeps the register. This commit also adds a custom printer for these operands, which matches the GCC canonical printer, printing both `(a0)` and `0(a0)` as `(a0)`. Reviewers: asb, lewis-revill Reviewed By: asb Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65205 llvm-svn: 367553 Merge commit f596f4507 from llvm git (by Sam Elliott): [RISCV] Add FreeBSD targets Reviewers: asb Reviewed By: asb Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57795 Patch by James Clarke (jrtc27) llvm-svn: 367557 Merge commit f596f4507 from llvm git (by Hsiangkai Wang): [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame. It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366524 Merge commit f596f4507 from llvm git (by Hsiangkai Wang): [DebugInfo] Some fields do not need relocations even relax is enabled. In debug frame information, some fields, e.g., Length in CIE/FDE and Offset in FDE are attributes to describe the structure of CIE/FDE. They are not related to the relaxed code. However, these attributes are symbol differences. So, in current design, these attributes will be filled as zero and LLVM generates relocations for them. We only need to generate relocations for symbols in executable sections. So, if the symbols are not located in executable sections, we still evaluate their values under relaxation. Differential Revision: https://reviews.llvm.org/D61584 llvm-svn: 366531 Merge commit f596f4507 from llvm git (by Alex Bradbury): [RISCV] Don't force absolute FK_Data_X fixups to relocs The current behavior of shouldForceRelocation forces relocations for the majority of fixups when relaxation is enabled. This makes sense for fixups which incorporate symbols but is unnecessary for simple data fixups where the fixup target is already resolved to an absolute value. Differential Revision: https://reviews.llvm.org/D63404 Patch by Edward Jones. llvm-svn: 369257 Merge commit f596f4507 from llvm git (by Alex Bradbury): [RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is used for the FDE location Follow binutils in using RISCV_32_PCREL for the FDE initial location. As explained in the relevant binutils commit <https://github.com/riscv/riscv-binutils-gdb/commit/a6cbf936e3dce68114d28cdf60d510a3f78a6d40>, the ADD/SUB pair of relocations is problematic in the presence of linker relaxation. This patch has the same end goal as D64715 but includes test changes and avoids adding a new global VariantKind to MCExpr.h (preferring RISCVMCExpr VKs like the rest of the RISC-V backend). Differential Revision: https://reviews.llvm.org/D66419 llvm-svn: 369375 This series of merges will permit riscv64 kernels and riscv64sf worlds to build with clang instead of gcc (but still using the bfd linker). Requested by: jhb Obtained from: https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang MFC r354662 (by jhb): Sync target triple generation with the version in Makefile.inc1. Reviewed by: dim Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D22333 MFC r354692 (by emaste): llvm: use AT_EXECPATH from ELF auxiliary vectors for getExecutablePath /proc/curproc/file and the KERN_PROC_PATHNAME sysctl may not return the desired path if there are multiple hardlinks to the file. PR: 241932 Tested by: ler Sponsored by: The FreeBSD Foundation MFC r354707 (by emaste): llvm: use elf_aux_info to get executable's path, if available Obtained from: LLVM a0a38b81ea MFC with: r354692 Sponsored by: The FreeBSD Foundation MFC r354979: Merge commit 7bed381ea from llvm git (by Simon Atanasyan): [mips] Implement Octeon+ `saa` and `saad` instructions `saa` and `saad` are 32-bit and 64-bit store atomic add instructions. memory[base] = memory[base] + rt These instructions are available for "Octeon+" CPU. The patch adds support for both instructions to MIPS assembler and diassembler and introduces new CPU type - "octeon+". Next patches will implement `.set arch=octeon+` directive and `AFL_EXT_OCTEONP` ISA extension flag support. Differential Revision: https://reviews.llvm.org/D69849 This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC r354980: Merge commit 3718102d4 from llvm git (by Simon Atanasyan): [mips] Support `octeon+` CPU in the `.set arch=` directive Differential Revision: https://reviews.llvm.org/D69850 This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC r354981: Merge commit bf996f761 from llvm git (by Simon Atanasyan): [mips] Write `AFL_EXT_OCTEONP` flag to the `.MIPS.abiflags` section Differential Revision: https://reviews.llvm.org/D69851 This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC r354982: Merge commit 3552d3e0f from llvm git (by Simon Atanasyan): [mips] Add `octeon+` to the list of CPUs accepted by the driver This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC r354983: Merge commit e578d0fd2 from llvm git (by Simon Atanasyan): [mips] Fix `__mips_isa_rev` macros value for Octeon CPU This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC r354984: Merge commit 0d14656b9 from llvm git (by Simon Atanasyan): [mips] Set __OCTEON__ macros This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC r354985: Merge commit a751f557d from llvm git (by Simon Atanasyan): [mips] Set macros for Octeon+ CPU This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC r355397: Merge commit 241cbf201 from llvm git (by Nemanja Ivanovic): [PowerPC] Fix crash in peephole optimization When converting reg+reg shifts to reg+imm rotates, we neglect to consider the CodeGenOnly versions of the 32-bit shift mnemonics. This means we produce a rotate with missing operands which causes a crash. Committing this fix without review since it is non-controversial that the list of mnemonics to consider should include the 64-bit aliases for the exact mnemonics. Fixes PR44183. This should fix "Assertion failed: (idx < size()), function operator[], file /usr/src/contrib/llvm/include/llvm/ADT/SmallVector.h, line 153" when building the graphics/mesa-dri port for the PowerPC64 ELFv2 ABI. Reported by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br> MFC r355602: Add a few missed source files to libllvm, for the MK_LLVM_TARGET_BPF=yes case. Otherwise, linking of clang and other llvm based executables would complain about missing symbols. Reported by: rstone MFC r355645 (by cem): arm: libgcc_s: Fix ABI breakage introduced in r354347 Provide the symbol version for llvm-libunwind's _Unwind_Backtrace that libgcc has historically provided on arm, in addition to the (default) standard version used on all other arch. Reported by: mmel MFC r355803 (by mmel): Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM. In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version for all architectures but ARM. For ARM should be publishes with GCC_4.3.0 version. This was originally omitted in r255095, fixed in r318024 and omitted aging in LLVM libunwind implementation in r354347. For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0 version , (because this is right original version) and again as normal(not-default) with GCC_3.3 version (to maintain ABI compatibility compiled/linked with wrong pre r318024 libgcc) PR: 233664 Notes: svn path=/stable/11/; revision=360658
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2019-04-161-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 8.0.0 final release r356365. MFC r306265 (by emaste): Force LLVM_LIBUNWIND off if we don't have a C++11 compiler Tested by: bde Differential Revision: https://reviews.freebsd.org/D7746 MFC r308100 (by emaste): compile libunwind c source with -fexceptions When an exception is thrown the unwinder must unwind its own C source (starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to be built with unwinding data. MFC r324998 (by bdrewery): Prefix {TARGET,BUILD}_TRIPLE with LLVM_ to avoid Makefile.inc1 collision. The Makefile.inc1 TARGET_TRIPLE is for specifying which -target is used during the build of world. Reviewed by: dim, imp Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12792 MFC r329093 (by emaste): Promote llvm-cov to a standalone option Introduce WITH_/WITHOUT_LLVM_COV to match GCC's WITH_/WITHOUT_GCOV. It is intended to provide a superset of the interface and functionality of gcov. It is enabled by default when building Clang, similarly to gcov and GCC. This change moves one file in libllvm to be compiled unconditionally. Previously it was included only when WITH_CLANG_EXTRAS was set, but the complexity of a new special case for (CLANG_EXTRAS | LLVM_COV) is not worth avoiding a tiny increase in build time. Reviewed by: dim, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D142645 MFC r331244 (by jhb): Add support for MIPS to LLVM's libunwind. This is originally based on a patch from David Chisnall for soft-float N64 but has since been updated to support O32, N32, and hard-float ABIs. The soft-float O32, N32, and N64 support has been committed upstream. The hard-float changes are still in review upstream. Enable LLVM_LIBUNWIND on mips when building with a suitable (C+11-capable) toolchain. This has been tested with external GCC for all ABIs and O32 and N64 with clang. Reviewed by: emaste Obtained from: CheriBSD (original N64 patch) Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D14701 MFC r336691 (by emaste): llvm: remove __FreeBSD_version conditionals All supported FreeBSD build host versions have backtrace.h, so we can just eliminate that test. For futimes() we can test the compiler's built-in __FreeBSD__ major version rather than relying on including osreldate.h. This should reduce the frequency with which Clang gets rebuilt when building world. Reviewed by: dim Sponsored by: The FreeBSD Foundation MFC r337379 (by andrew): Default to armv5te in LINT on arm. This should fix building LINT there. MFC r337552: Add optional LLVM BPF target support BPF (eBPF) is an independent instruction set architecture which is introduced in Linux a few years ago. Originally, eBPF execute environment was only inside Linux kernel. However, recent years there are some user space implementation (https://github.com/iovisor/ubpf, https://doc.dpdk.org/guides/prog_guide/bpf_lib.html) and kernel space implementation for FreeBSD is going on (https://github.com/YutaroHayakawa/generic-ebpf). The BPF target support can be enabled using WITH_LLVM_TARGET_BPF, as it is not built by default. Submitted by: Yutaro Hayakawa <yhayakawa3720@gmail.com> Reviewed by: dim, bdrewery Differential Revision: https://reviews.freebsd.org/D16033 MFC r337585: In r308100, an explicit -fexceptions flag was added for the C sources from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so. This is because the unwinder needs the unwinder data for its own functions. However, for the C++ sources in libunwind, -fexceptions is already the default, and this can have the side effect of generating a reference to __gxx_personality_v0, the so-called personality function, which is normally provided by the C++ ABI library (libcxxrt or libsupc++). If the reference ends up in the eventual libgcc_s.so, linking any non-C++ programs against it will fail with "undefined reference to `__gxx_personality_v0'". Note that at high optimization levels, the reference is usually optimized away, which is why we have never noticed this problem before. With clang 7.0.0 though, higher optimization levels don't help anymore, since the addition of address-significance tables [1] in <https://reviews.llvm.org/rL337339>. Effectively, this always causes a reference to __gxx_personality_v0. After discussion with the upstream author of that change, it turns out that we should compile libunwind sources with the -fno-exceptions -funwind-tables flags instead. This ensures unwind tables are generated, but no references to any personality functions are emitted. [1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html Reported by: jbeich PR: 230399 MFC r340287 (by emaste): Consolidate gcov entries in OptionalObsoleteFiles Sponsored by: The FreeBSD Foundation MFC r340289 (by emaste): llvm-cov: also install as gcov (if GNU gcov is disabled) llvm-cov provides a gcov-compatible interface when invoked as gcov. Reviewed by: dim, markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17923 MFC r340296 (by emaste): Move llvm-profdata build into MK_LLVM_COV block llvm-profdata is used with llvm-cov for code coverage (although llvm-cov can also operate independently in a gcov-compatible mode). Although llvm-profdata can be used independently of llvm-cov it makes sense to group these under one option. Also handle these in OptionalObsoleteFiles.inc while here. Sponsored by: The FreeBSD Foundation MFC r340300 (by emaste): libllvm: Move SampleProfWriter to SRCS_MIN It is required by llvm-profdata, now built by default under the LLVM_COV knob. The additional complexity that would come from avoiding building it if CLANG_EXTRAS and LLVM_COV are both disabled is not worth the small savings in build time. Sponsored by: The FreeBSD Foundation MFC r340972 (by emaste): llvm-objdump: initial man page Based on llvm-objdump's online documentation and usage information. This serves as a starting point; additional detail and cleanup still required. Also being submitted upstream in LLVM review D54864. I expect to use this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we update to LLVM 8.0 it should be upstream and we will switch to it. PR: 233437 Reviewed by: bcr (man formatting) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18309 MFC r340973 (by emaste): llvm-objdump.1: remove invalid options Some options appear in llvm-objdump's usage information as a side effect of its option parsing implementation and are not actually llvm-objdump options. Reported in LLVM review https://reviews.llvm.org/D54864. Reported by: Fangrui Song Sponsored by: The FreeBSD Foundation MFC r340975 (by emaste): llvm-objdump.1: fix igor / mandoc -Tlint warnings Accidentally omitted from r340972. MFC r341055 (by emaste): llvm-objdump.1: remove more unintentional options Some options come from static constructors in LLVM libraries and are automatically added to llvm's usage output. They're not really supposed to be llvm-objdump options. Reported by: Fangrui Song in LLVM review D54864 Sponsored by: The FreeBSD Foundation MFC r344779: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html> PR: 236062 Relnotes: yes MFC r344798 (by emaste): libllvm: promote WithColor and xxhash to SRCS_MIN The armv6 build failed in CI due to missing symbols (from these two source files) in the bootstrap Clang. This affected only armv6 because other Clang-using archs are using LLD as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP. Reported by: CI, via lwhsu Sponsored by: The FreeBSD Foundation MFC r344825: Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise clang and various other executables will fail to link with undefined symbols. Reported by: O. Hartmann <ohartmann@walstatt.org> MFC r344852: Put in a temporary workaround for what is likely a gcc 6 bug (it does not occur with gcc 7 or later). This should prevent the following error from breaking the head-amd64-gcc CI builds: In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0: /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>' using std::vector<lldb_private::MemoryRegionInfo>::vector; ^~~~~~ /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>' Reported by: CI MFC r344896: Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger): Fix inline assembler constraint validation The current constraint logic is both too lax and too strict. It fails for input outside the [INT_MIN..INT_MAX] range, but it also implicitly accepts 0 as value when it should not. Adjust logic to handle both correctly. Differential Revision: https://reviews.llvm.org/D58649 Pull in r355491 from upstream clang trunk (by Hans Wennborg): Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890) Apparently GCC allows this, and there's code relying on it (see bug). The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()). Differential Revision: https://reviews.llvm.org/D58821 These should fix assertions and errors when using the inline assembly "n" constraint in certain ways. In case of devel/valgrind, a pointer was used as the input for the constraint, which lead to "Assertion failed: (isInt() && "Invalid accessor"), function getInt". In case of math/secp256k1, a very large integer value was used as input for the constraint, which lead to "error: value '4624529908474429119' out of range for constraint 'n'". PR: 236216, 236194 MFC r344951: Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version numbers. PR: 236062 MFC r345018: Merge LLVM libunwind trunk r351319, from just before upstream's release_80 branch point. Afterwards, we will merge the rest of the changes in the actual release_80 branch. PR: 236062 MFC r345019: Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4). PR: 236062 MFC r345021: Pull in r355854 from upstream llvm trunk (by Jonas Paulsson): [RegAlloc] Avoid compile time regression with multiple copy hints. As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints(). This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint(). Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201 This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port. PR: 236313 MFC r345068 (by jhb): Move libunwind out of contrib/llvm/projects. Move LLVM's libunwind to its own contrib/ directory similar to other runtime libraries like libc++ and libcxxrt. Reviewed by: dim, emaste Differential Revision: https://reviews.freebsd.org/D19534 MFC r345073: Revert r308867 (which was originally committed in the clang390-import project branch): Work around LLVM PR30879, which is about a bad interaction between X86 Call Frame Optimization on i386 and libunwind, by disallowing the optimization for i386-freebsd12. This should fix some instances of broken exception handling when frame pointers are omitted, in particular some unittests run during the build of editors/libreoffice. This hack will be removed as soon as upstream has implemented a more permanent fix for this problem. And indeed, after r345018 and r345019, which updated LLVM libunwind to the most recent version, the above workaround is no longer needed. The upstream commit which fixed this is: https://llvm.org/viewvc/llvm-project?view=revision&revision=292723 Specifically, 32 bit (i386-freebsd) executables optimized with omitted frame pointers and Call Frame Optimization should now behave correctly when a C++ exception is thrown, and the stack is unwound. Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879 PR: 236062 MFC r345152: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts, and bump version numbers. PR: 236062 MFC r345231: Add LLVM openmp trunk r351319 (just before the release_80 branch point) to contrib/llvm. This is not yet connected to the build, the glue for that will come in a follow-up commit. PR: 236062 MFC r345232: Bootstrap svn:mergeinfo on contrib/openmp. PR: 236062 MFC r345233: Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5). PR: 236062 MFC r345234: Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3). This has also been submitted upstream. PR: 236062 MFC r345283: Enable building libomp.so for 32-bit x86. This is done by selectively enabling the functions that save and restore MXCSR, since access to this register requires SSE support. Note that you may run into other issues with OpenMP on i386, since this *not* yet supported upstream, and certainly not extensively tested. PR: 236062, 236582 MFC r345345: Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365. There were no functional changes since the most recent merge, of 8.0.0 rc5. Release notes for llvm, clang, lld and libc++ 8.0.0 are now available: https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 236062 MFC r345349: Pull in r352826 from upstream lld trunk (by Fangrui Song): [ELF] Support --{,no-}allow-shlib-undefined Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 Pull in r352943 from upstream lld trunk (by Fangrui Song): [ELF] Default to --no-allow-shlib-undefined for executables Summary: This follows the ld.bfd/gold behavior. The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors: // a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); } // b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); } // ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: llvm-commits, emaste, arichardson Tags: #llvm Differential Revision: https://reviews.llvm.org/D57569 Together, these add support for --no-allow-shlib-undefined, and make it the default for executables, so they will fail to link if any symbols from needed shared libraries are undefined. Reported by: jbeich PR: 236062, 236141 MFC r345449: Pull in r356809 from upstream llvm trunk (by Eli Friedman): [ARM] Don't form "ands" when it isn't scheduled correctly. In r322972/r323136, the iteration here was changed to catch cases at the beginning of a basic block... but we accidentally deleted an important safety check. Restore that check to the way it was. Fixes https://bugs.llvm.org/show_bug.cgi?id=41116 Differential Revision: https://reviews.llvm.org/D59680 This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe port for armv7. PR: 236062, 236568 Notes: svn path=/stable/11/; revision=346296
* Merge clang 7.0.1 and several follow-up changesDimitry Andric2019-02-161-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MFC r318594: Add libc++experimental.a for std::experimental support This adds a separate library for supporting std::experimental features. It is purposefully static, and must be explicitly linked into programs using -lc++experimental. PLEASE NOTE: there is NO WARRANTY as to any stability or continuing existence of the features in the std::experimental parts of the C++ library! Reviewed by: ed Differential Revision: https://reviews.freebsd.org/D10840 MFC r318598: Add PICFLAG to build libc++experimental.a, so it can be used in all situations. Noticed by: kib r336969 | emaste | 2018-07-31 16:12:09 +0200 (Tue, 31 Jul 2018) | 13 lines llvm: [ELF][ARM] Add Arm ABI names for float ABI ELF Header flags The ELF for the Arm architecture document defines, for EF_ARM_EABI_VER5 and above, the flags EF_ARM_ABI_FLOAT_HARD and EF_ARM_ABI_FLOAT_SOFT. These have been defined to be compatible with the existing EF_ARM_VFP_FLOAT and EF_ARM_SOFT_FLOAT used by gcc for EF_ARM_EABI_UNKNOWN. This patch adds the flags in addition to the existing ones so that any code depending on the old names will still work. Obtained from: llvm r338370 by Peter Smith r336970 | emaste | 2018-07-31 16:14:41 +0200 (Tue, 31 Jul 2018) | 9 lines llvm: [ARM] Complete enumeration values for Tag_ABI_VFP_args The LLD implementation of Tag_ABI_VFP_args needs to check the rarely seen values of 3 (toolchain specific) and 4 compatible with both Base and VFP. Add the missing enumeration values so that LLD can refer to them without having to use the raw numbers. Obtained from: llvm r338373 by Peter Smith r336972 | emaste | 2018-07-31 17:25:03 +0200 (Tue, 31 Jul 2018) | 37 lines lld: [ELF][ARM] Implement support for Tag_ABI_VFP_args The Tag_ABI_VFP_args build attribute controls the procedure call standard used for floating point parameters on ARM. The values are: 0 - Base AAPCS (FP Parameters passed in Core (Integer) registers 1 - VFP AAPCS (FP Parameters passed in FP registers) 2 - Toolchain specific (Neither Base or VFP) 3 - Compatible with all (No use of floating point parameters) If the Tag_ABI_VFP_args build attribute is missing it has an implicit value of 0. We use the attribute in two ways: * Detect a clash in calling convention between Base, VFP and Toolchain. we follow ld.bfd's lead and do not error if there is a clash between an implicit Base AAPCS caused by a missing attribute. Many projects including the hard-float (VFP AAPCS) version of glibc contain assembler files that do not use floating point but do not have Tag_ABI_VFP_args. * Set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD ELF header flag for Base or VFP AAPCS respectively. This flag is used by some ELF loaders. References: * Addenda to, and Errata in, the ABI for the ARM Architecture for Tag_ABI_VFP_args * Elf for the ARM Architecture for ELF header flags Fixes LLVM PR36009 PR: 229050 Obtained from: llvm r338377 by Peter Smith r337282 | alc | 2018-08-04 04:30:51 +0200 (Sat, 04 Aug 2018) | 7 lines Set the default image base on arm64 and i386 to a superpage-aligned address. Reviewed by: emaste, markj Discussed with: dim Differential Revision: https://reviews.freebsd.org/D16385 r339304 | emaste | 2018-10-11 15:19:17 +0200 (Thu, 11 Oct 2018) | 13 lines lld: set sh_link and sh_info for .rela.plt sections ELF spec says that for SHT_REL and SHT_RELA sh_link should reference the associated string table and sh_info should reference the "section to which the relocation applies." ELF Tool Chain's elfcopy / strip use this (in part) to control whether or not the relocation entry is copied to the output. LLVM PR 37538 https://bugs.llvm.org/show_bug.cgi?id=37538 Approved by: re (kib) Obtained from: llvm r344226 (backported for 6.0) MFC r341825: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected. Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html> PR: 230240, 230355 Relnotes: yes MFC r342123: Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to 7.0.1 release r349250. There were no functional changes since the 7.0.1 rc3 import. PR: 230240, 230355 Relnotes: yes r343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 lines clang: default to DWARF 4 as of FreeBSD 13 FreeBSD previously defaulted to DWARF 2 because several tools (gdb, ctfconvert, etc.) did not support later versions. These have either been fixed or are deprecated. Note that gdb 6 still exists but has been moved out of $PATH into /usr/libexec and is intended only for use by crashinfo(8). The kernel build sets the DWARF version explicitly via -gdwarf2, so this should have no effect there. PR: 234887 [exp-run] Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17930 MFC r343916: Pull in r352607 from upstream llvm trunk (by Craig Topper): [X86] Add FPSW as a Def on some FP instructions that were missing it. Pull in r353141 from upstream llvm trunk (by Craig Topper): [X86] Connect the default fpsr and dirflag clobbers in inline assembly to the registers we have defined for them. Summary: We don't currently map these constraints to physical register numbers so they don't make it to the MachineIR representation of inline assembly. This could have problems for proper dependency tracking in the machine schedulers though I don't have a test case that shows that. Reviewers: rnk Reviewed By: rnk Subscribers: eraman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57641 Pull in r353489 from upstream llvm trunk (by Craig Topper): [X86] Add FPCW as a register and start using it as an implicit use on floating point instructions. Summary: FPCW contains the rounding mode control which we manipulate to implement fp to integer conversion by changing the roudning mode, storing the value to the stack, and then changing the rounding mode back. Because we didn't model FPCW and its dependency chain, other instructions could be scheduled into the middle of the sequence. This patch introduces the register and adds it as an implciit def of FLDCW and implicit use of the FP binary arithmetic instructions and store instructions. There are more instructions that need to be updated, but this is a good start. I believe this fixes at least the reduced test case from PR40529. Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor Subscribers: dim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57735 These should fix a problem in clang 7.0 where it would sometimes emit long double floating point instructions in a slightly wrong order, leading to failures in our libm tests. In particular, the cbrt_test test case 'cbrtl_powl' and the trig_test test case 'reduction'. Also bump __FreeBSD_cc_version, to be able to detect this in our test suite. Reported by: lwhsu PR: 234040 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206 MFC r344056: Pull in r339734 from upstream llvm trunk (by Eli Friedman): [ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly. Intentionally excluding nodes from the DAGCombine worklist is likely to lead to weird optimizations and infinite loops, so it's generally a bad idea. To avoid the infinite loops, fix DAGCombine to use the isDesirableToCommuteWithShift target hook before performing the transforms in question, and implement the target hook in the ARM backend disable the transforms in question. Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a reduced testcase for that bug. But we should have sufficient test coverage for PerformSHLSimplify given that we're not playing weird tricks with the worklist. I can try to bugpoint it if necessary, though.) Differential Revision: https://reviews.llvm.org/D50667 This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c (which exists now only in the stable/11 branch) for arm. Notes: svn path=/stable/11/; revision=344213
* Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release:Dimitry Andric2017-04-021-15/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/stable/11/; revision=316423
* MFC r309124:Dimitry Andric2016-12-261-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/stable/11/; revision=310618
* Update clang to trunk r256633.Dimitry Andric2015-12-301-0/+17
| | | | Notes: svn path=/projects/clang380-import/; revision=292942
* Merge llvm 3.6.0rc1 from ^/vendor/llvm/dist, merge clang 3.6.0rc1 fromDimitry Andric2015-01-251-5/+2
| | | | | | | ^/vendor/clang/dist, resolve conflicts, and cleanup patches. Notes: svn path=/projects/clang360-import/; revision=277718
* Merge clang 3.5.0 release from ^/vendor/clang/dist, resolve conflicts,Dimitry Andric2014-11-241-5/+6
| | | | | | | and preserve our customizations, where necessary. Notes: svn path=/projects/clang350-import/; revision=274969
* Upgrade our copy of llvm/clang to 3.4 release. This version supportsDimitry Andric2014-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | all of the features in the current working draft of the upcoming C++ standard, provisionally named C++1y. The code generator's performance is greatly increased, and the loop auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The PowerPC backend has made several major improvements to code generation quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ backends have all seen major feature work. Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.4/docs/ReleaseNotes.html> <http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html> MFC after: 1 month Notes: svn path=/head/; revision=261991
* Upgrade our copy of llvm/clang to trunk r178860, in preparation of theDimitry Andric2013-04-121-9/+52
| | | | | | | | | | | | upcoming 3.3 release (branching and freezing expected in a few weeks). Preliminary release notes can be found at the usual location: <http://llvm.org/docs/ReleaseNotes.html> An MFC is planned once the actual 3.3 release is finished. Notes: svn path=/head/; revision=249423
* Upgrade our copy of llvm/clang to r168974, from upstream's release_32Dimitry Andric2012-12-031-1/+0
| | | | | | | | branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is coming soon. Notes: svn path=/head/; revision=243830
* Upgrade our copy of llvm/clang to trunk r162107. With thanks toDimitry Andric2012-08-201-21/+24
| | | | | | | Benjamin Kramer and Joerg Sonnenberger for their input and fixes. Notes: svn path=/head/; revision=239462
* Upgrade our copy of llvm/clang to trunk r154661, in preparation of theDimitry Andric2012-04-161-14/+21
| | | | | | | | | | upcoming 3.1 release (expected in a few weeks). Preliminary release notes can be found at: <http://llvm.org/docs/ReleaseNotes.html> MFC after: 2 weeks Notes: svn path=/head/; revision=234353
* Upgrade our copy of llvm/clang to r142614, from upstream's release_30Dimitry Andric2011-10-221-3/+3
| | | | | | | | | | branch. This brings us very close to the 3.0 release, which is expected in a week or two. MFC after: 1 week Notes: svn path=/head/; revision=226633
* Upgrade our copy of llvm/clang to r135360, from upstream's trunk.Dimitry Andric2011-07-171-2/+7
| | | | Notes: svn path=/head/; revision=224145
* Upgrade our copy of llvm/clang to r130700, from upstream's trunk.Dimitry Andric2011-05-021-3/+20
| | | | Notes: svn path=/head/; revision=221345
* Upgrade our copy of llvm/clang to r126079, from upstream's trunk.Dimitry Andric2011-02-201-24/+0
| | | | | | | | This contains many improvements, primarily better C++ support, an integrated assembler for x86 and support for -pg. Notes: svn path=/head/; revision=218893
* Upgrade our Clang in base to r114020, from upstream's release_28 branch.Dimitry Andric2010-09-201-0/+114
Approved-by: rpaulo (mentor) Notes: svn path=/head/; revision=212904
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 17:22:24 +0000