| #
360658 |
|
05-May-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
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
|
| #
344213 |
|
16-Feb-2019 |
dim |
Merge clang 7.0.1 and several follow-up changes
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.
|
| #
331838 |
|
31-Mar-2018 |
dim |
Merge clang, llvm, lld, lldb, compiler-rt and libc++ 6.0.0 release, and
several follow-up fixes.
MFC r327952:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r321788). Upstream has branched for the
6.0.0 release, which should be in about 6 weeks. 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 r328010:
Pull in r322473 from upstream llvm trunk (by Andrei Elovikov):
[LV] Don't call recordVectorLoopValueForInductionCast for
newly-created IV from a trunc.
Summary:
This method is supposed to be called for IVs that have casts in their
use-def chains that are completely ignored after vectorization under
PSE. However, for truncates of such IVs the same InductionDescriptor
is used during creation/widening of both original IV based on PHINode
and new IV based on TruncInst.
This leads to unintended second call to
recordVectorLoopValueForInductionCast with a VectorLoopVal set to the
newly created IV for a trunc and causes an assert due to attempt to
store new information for already existing entry in the map. This is
wrong and should not be done.
Fixes PR35773.
Reviewers: dorit, Ayal, mssimpso
Reviewed By: dorit
Subscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D41913
This should fix "Vector value already set for part" assertions when
building the net/iodine and sysutils/daa2iso ports.
Reported by: jbeich
PR: 224867, 224868
MFC r328090:
Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):
Allow usage of X86-prefixes as separate instrs.
Differential Revision: https://reviews.llvm.org/D42102
This should fix parse errors when x86 prefixes (such as 'lock' and
'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte
directives and labels.
PR: 224669, 225054
MFC r328091:
Revert r327340, as the workaround for rep prefixes followed by .byte
directives is no longer needed after r328090.
MFC r328141 (by emaste):
lld: Fix for ld.lld does not accept "AT" syntax for declaring LMA region
AT> lma_region expression allows to specify the memory region
for section load address.
Should fix [upstream LLVM] PR35684.
LLVM review: https://reviews.llvm.org/D41397
Obtained from: LLVM r322359 by George Rimar
MFC r328143 (by emaste):
lld: Handle parsing AT(ADDR(.foo-bar)).
The problem we had with it is that anything inside an AT is an
expression, so we failed to parse the section name because of the - in
it.
Requested by: royger
Obtained from: LLVM r322801 by Rafael Espindola
MFC r328144 (by emaste):
lld: Fix incorrect physical address on self-referencing AT command.
When a section placement (AT) command references the section itself,
the physical address of the section in the ELF header was calculated
incorrectly due to alignment happening right after the location
pointer's value was captured.
The problem was diagnosed and the first version of the patch written
by Erick Reyes.
Obtained from: LLVM r322421 by Rafael Espindola
MFC r328145:
Pull in r322016 from upstream llvm trunk (by Sanjay Patel):
[ValueTracking] remove overzealous assert
The test is derived from a failing fuzz test:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5008
Credit to @rksimon for pointing out the problem.
This should fix "Bad flavor while matching min/max" errors when building
the graphics/libsixel and science/kst2 ports.
Reported by: jbeich
PR: 225268, 225269
MFC r328146:
Pull in r322106 from upstream llvm trunk (by Alexey Bataev):
[COST]Fix PR35865: Fix cost model evaluation for shuffle on X86.
Summary:
If the vector type is transformed to non-vector single type, the
compile may crash trying to get vector information about non-vector
type.
Reviewers: RKSimon, spatel, mkuper, hfinkel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41862
This should fix "Not a vector MVT!" errors when building the
games/dhewm3 port.
Reported by: jbeich
PR: 225271
MFC r328286 (by emaste):
lld: Don't mark a shared library as needed because of a lazy symbol.
Obtained from: LLVM r323221 by Rafael Esp?ndola
MFC r328381:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r323338).
PR: 224669
MFC r328513:
Pull in r322245 from upstream clang trunk (by Craig Topper):
[X86] Make -mavx512f imply -mfma and -mf16c in the frontend like it
does in the backend.
Similarly, make -mno-fma and -mno-f16c imply -mno-avx512f.
Withou this "-mno-sse -mavx512f" ends up with avx512f being enabled
in the frontend but disabled in the backend.
Reported by: pawel
PR: 225488
MFC r328542 (by emaste):
lld: Use lookup instead of find. NFC, just simpler.
Obtained from: LLVM r323395 by Rafael Espindola
MFC r328543 (by emaste):
lld: Only lookup LMARegion once. NFC.
This is similar to how we handle MemRegion.
Obtained from: LLVM r323396 by Rafael Espindola
MFC r328544 (by emaste):
lld: Remove MemRegionOffset. NFC.
We can just use a member variable in MemoryRegion.
Obtained from: LLVM r323399 by Rafael Espindola
MFC r328545 (by emaste):
lld: Simplify. NFC.
Obtained from: LLVM r323440 by Rafael Espindola
MFC r328546 (by emaste):
lld: Improve LMARegion handling.
This fixes the crash reported at [LLVM] PR36083.
The issue is that we were trying to put all the sections in the same
PT_LOAD and crashing trying to write past the end of the file.
This also adds accounting for used space in LMARegion, without it all
3 PT_LOADs would have the same physical address.
Obtained from: LLVM r323449 by Rafael Espindola
MFC r328547 (by emaste):
lld: Move LMAOffset from the OutputSection to the PhdrEntry. NFC.
If two sections are in the same PT_LOAD, their relatives offsets,
virtual address and physical addresses are all the same.
[Rafael] initially wanted to have a single global LMAOffset, on the
assumption that every ELF file was in practiced loaded contiguously in
both physical and virtual memory.
Unfortunately that is not the case. The linux kernel has:
LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0xced000 0xced000 R E 0x200000
LOAD 0x1000000 0xffffffff81e00000 0x0000000001e00000 0x15f000 0x15f000 RW 0x200000
LOAD 0x1200000 0x0000000000000000 0x0000000001f5f000 0x01b198 0x01b198 RW 0x200000
LOAD 0x137b000 0xffffffff81f7b000 0x0000000001f7b000 0x116000 0x1ec000 RWE 0x200000
The delta for all but the third PT_LOAD is the same:
0xffffffff80000000. [Rafael] thinks the 3rd one is a hack for implementing
per cpu data, but we can't break that.
Obtained from: LLVM r323456 by Rafael Espindola
MFC r328548 (by emaste):
lld: Put the header in the first PT_LOAD even if that PT_LOAD has a LMAExpr
The root problem is that we were creating a PT_LOAD just for the header.
That was technically valid, but inconvenient: we should not be making
the ELF discontinuous.
The solution is to allow a section with LMAExpr to be added to a PT_LOAD
if that PT_LOAD doesn't already have a LMAExpr.
LLVM PR: 36017
Obtained from: LLVM r323625 by Rafael Espindola
MFC r328594 (by emaste):
Pull in r322108 from upstream llvm trunk (by Rafael Esp?ndola):
Make one of the emitFill methods non virtual. NFC.
This is just preparatory work to fix [LLVM] PR35858.
MFC r328595 (by emaste):
Pull in r322123 from upstream llvm trunk (by Rafael Esp?ndola):
Don't create MCFillFragment directly.
Instead use higher level APIs that take care of most bookkeeping.
MFC r328596 (by emaste):
Pull in r322131 from upstream llvm trunk (by Rafael Esp?ndola):
Use a MCExpr for the size of MCFillFragment.
This allows the size to be found during ralaxation. This fixes
[LLVM] pr35858.
Requested by: royger
MFC r328753:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r323948).
PR: 224669
MFC r328817:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r324090).
This introduces retpoline support, with the -mretpoline flag. The
upstream initial commit message (r323155 by Chandler Carruth) contains
quite a bit of explanation. Quoting:
Introduce the "retpoline" x86 mitigation technique for variant #2 of
the speculative execution vulnerabilities disclosed today,
specifically identified by CVE-2017-5715, "Branch Target Injection",
and is one of the two halves to Spectre.
Summary:
First, we need to explain the core of the vulnerability. Note that
this is a very incomplete description, please see the Project Zero
blog post for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative
execution of the processor to some "gadget" of executable code by
poisoning the prediction of indirect branches with the address of
that gadget. The gadget in turn contains an operation that provides a
side channel for reading data. Most commonly, this will look like a
load of secret data followed by a branch on the loaded value and then
a load of some predictable cache line. The attacker then uses timing
of the processors cache to determine which direction the branch took
*in the speculative execution*, and in turn what one bit of the
loaded value was. Due to the nature of these timing side channels and
the branch predictor on Intel processors, this allows an attacker to
leak data only accessible to a privileged domain (like the kernel)
back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional branches
and a small search tree. LLVM already has support for lowering
switches in this way and the first step of this patch is to disable
jump-table lowering of switches and introduce a pass to rewrite
explicit indirectbr sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as a
trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures
the processor predicts the return to go to a controlled, known
location. The retpoline then "smashes" the return address pushed onto
the stack by the call with the desired target of the original
indirect call. The result is a predicted return to the next
instruction after a call (which can be used to trap speculative
execution within an infinite loop) and an actual indirect branch to
an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this
device. For 32-bit ABIs there isn't a guaranteed scratch register
and so several different retpoline variants are introduced to use a
scratch register if one is available in the calling convention and to
otherwise use direct stack push/pop sequences to pass the target
address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the
retpoline thunk by the compiler to allow for custom thunks if users
want them. These are particularly useful in environments like
kernels that routinely do hot-patching on boot and want to hot-patch
their thunk to different code sequences. They can write this custom
thunk and use `-mretpoline-external-thunk` *in addition* to
`-mretpoline`. In this case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are
from precompiled runtimes (such as crt0.o and similar). The ones we
have found are not really attackable, and so we have not focused on
them here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z
retpolineplt` (or use similar functionality from some other linker).
We strongly recommend also using `-z now` as non-lazy binding allows
the retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typic al workloads, and relatively minor hits (approximately
2%) even for extremely syscall-heavy applications. This is largely
due to the small number of indirect branches that occur in
performance sensitive paths of the kernel.
When using these patches on statically linked applications,
especially C++ applications, you should expect to see a much more
dramatic performance hit. For microbenchmarks that are switch,
indirect-, or virtual-call heavy we have seen overheads ranging from
10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically
reduce the impact of hot indirect calls (by speculatively promoting
them to direct calls) and allow optimized search trees to be used to
lower switches. If you need to deploy these techniques in C++
applications, we *strongly* recommend that you ensure all hot call
targets are statically linked (avoiding PLT indirection) and use both
PGO and ThinLTO. Well tuned servers using all of these techniques saw
5% - 10% overhead from the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality
available as soon as possible. Happy for more code review, but we'd
really like to get these patches landed and backported ASAP for
obvious reasons. We're planning to backport this to both 6.0 and 5.0
release streams and get a 5.0 release with just this cherry picked
ASAP for distros and vendors.
This patch is the work of a number of people over the past month:
Eric, Reid, Rui, and myself. I'm mailing it out as a single commit
due to the time sensitive nature of landing this and the need to
backport it. Huge thanks to everyone who helped out here, and
everyone at Intel who helped out in discussions about how to craft
this. Also, credit goes to Paul Turner (at Google, but not an LLVM
contributor) for much of the underlying retpoline design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
PR: 224669
MFC r329033:
Pull in r324594 from upstream clang trunk (by Alexander Ivchenko):
Fix for #31362 - ms_abi is implemented incorrectly for values >=16
bytes.
Summary:
This patch is a fix for following issue:
https://bugs.llvm.org/show_bug.cgi?id=31362 The problem was caused by
front end lowering C calling conventions without taking into account
calling conventions enforced by attribute. In this case win64cc was
no correctly lowered on targets other than Windows.
Reviewed By: rnk (Reid Kleckner)
Differential Revision: https://reviews.llvm.org/D43016
Author: belickim <mateusz.belicki@intel.com>
This fixes clang 6.0.0 assertions when building the emulators/wine and
emulators/wine-devel ports, and should also make it use the correct
Windows calling conventions. Bump __FreeBSD_version to make the fix
easy to detect.
PR: 224863
MFC r329223:
Pull in r323998 from upstream clang trunk (by Richard Smith):
PR36157: When injecting an implicit function declaration in C89, find
the right DeclContext rather than injecting it wherever we happen to
be.
This avoids creating functions whose DeclContext is a struct or
similar.
This fixes assertion failures when parsing certain not-completely-valid
struct declarations.
Reported by: ae
PR: 225862
MFC r329410:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r325330).
PR: 224669
MFC r329983:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r325932). This corresponds to 6.0.0 rc3.
PR: 224669
MFC r330384:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 release (upstream r326565).
Release notes for llvm, clang and lld will be available here soon:
<http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/6.0.0/tools/lld/docs/ReleaseNotes.html>
Relnotes: yes
PR: 224669
MFC r330686:
Pull in r326882 from upstream llvm trunk (by Sjoerd Meijer):
[ARM] Fix for PR36577
Don't PerformSHLSimplify if the given node is used by a node that
also uses a constant because we may get stuck in an infinite combine
loop.
bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36577
Patch by Sam Parker.
Differential Revision: https://reviews.llvm.org/D44097
This fixes a hang when compiling one particular file in java/openjdk8
for armv6 and armv7.
Reported by: swills
PR: 226388
MFC r331065:
Pull in r327638 from upstream llvm trunk (by Matthew Simpson):
[ConstantFolding, InstSimplify] Handle more vector GEPs
This patch addresses some additional cases where the compiler crashes
upon encountering vector GEPs. This should fix PR36116.
Differential Revision: https://reviews.llvm.org/D44219
Reference: https://bugs.llvm.org/show_bug.cgi?id=36116
This fixes an assertion when building the emulators/snes9x port.
Reported by: jbeich
PR: 225471
MFC r331066:
Pull in r321999 from upstream clang trunk (by Ivan A. Kosarev):
[CodeGen] Fix TBAA info for accesses to members of base classes
Resolves:
Bug 35724 - regression (r315984): fatal error: error in backend:
Broken function found (Did not see access type in access path!)
https://bugs.llvm.org/show_bug.cgi?id=35724
Differential Revision: https://reviews.llvm.org/D41547
This fixes "Did not see access type in access path" fatal errors when
building the devel/gdb port (version 8.1).
Reported by: jbeich
PR: 226658
MFC r331366:
Pull in r327101 from upstream llvm trunk (by Rafael Espindola):
Don't treat .symver as a regular alias definition.
This patch starts simplifying the handling of .symver.
For now it just moves the responsibility for creating an alias down to
the streamer. With that the asm streamer can pass a .symver unchanged,
which is nice since gas cannot parse "foo@bar = zed".
In a followup I hope to move the handling down to the writer so that
we don't need special hacks for avoiding breaking names with @@@ on
windows.
Pull in r327160 from upstream llvm trunk (by Rafael Espindola):
Delay creating an alias for @@@.
With this we only create an alias for @@@ once we know if it should
use @ or @@. This avoids last minutes renames and hacks to handle MS
names.
This only handles the ELF writer. LTO still has issues with @@@
aliases.
Pull in r327928 from upstream llvm trunk (by Vitaly Buka):
Object: Move attribute calculation into RecordStreamer. NFC
Summary: Preparation for D44274
Reviewers: pcc, espindola
Subscribers: hiraditya
Differential Revision: https://reviews.llvm.org/D44276
Pull in r327930 from upstream llvm trunk (by Vitaly Buka):
Object: Fix handling of @@@ in .symver directive
Summary:
name@@@nodename is going to be replaced with name@@nodename if symbols is
defined in the assembled file, or name@nodename if undefined.
https://sourceware.org/binutils/docs/as/Symver.html
Fixes PR36623
Reviewers: pcc, espindola
Subscribers: mehdi_amini, hiraditya
Differential Revision: https://reviews.llvm.org/D44274
Together, these changes fix handling of @@@ in .symver directives when
doing Link Time Optimization.
Reported by: Shawn Webb <shawn.webb@hardenedbsd.org>
MFC r331731:
Pull in r328738 from upstream lld trunk (by Rafael Espindola):
Strip @VER suffices from the LTO output.
This fixes pr36623.
The problem is that we have to parse versions out of names before LTO
so that LTO can use that information.
When we get the LTO produced .o files, we replace the previous symbols
with the LTO produced ones, but they still have @ in their names.
We could just trim the name directly, but calling parseSymbolVersion
to do it is simpler.
This is a follow-up to r331366, since we discovered that lld could
append version strings to symbols twice, when using Link Time
Optimization.
|
| #
310618 |
|
26-Dec-2016 |
dim |
MFC r309124:
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
|