Commit Graph

723 Commits

Author SHA1 Message Date
Dimitry Andric
653fac7d1a 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
2019-10-23 16:57:11 +00:00
Dimitry Andric
263323711d 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 after:	1 month
X-MFC-With:	r353358
2019-10-18 20:05:27 +00:00
Dimitry Andric
1b0cd7b6b4 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 after:	1 month
X-MFC-With:	r353358
2019-10-18 20:02:46 +00:00
Dimitry Andric
390ceeb437 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 after:	1 month
X-MFC-With:	r353358
2019-10-10 20:33:55 +00:00
Dimitry Andric
6cc0992fb5 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 after:	1 month
X-MFC-With:	r353358
2019-10-10 20:30:54 +00:00
Dimitry Andric
a930ecddaa 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 after:	1 month
X-MFC-With:	r353358
2019-10-09 19:51:41 +00:00
Dimitry Andric
8b1412a144 Pull in r372606 from upstream llvm trunk (by Sanjay Patel):
[x86] fix assert with horizontal math + broadcast of vector (PR43402)

  https://bugs.llvm.org/show_bug.cgi?id=43402

This should fix 'Assertion failed: ((HOp.getValueType() == MVT::v2f64 ||
HOp.getValueType() == MVT::v4f64) && HOp.getValueType() == VT &&
"Unexpected type for h-op"), function foldShuffleOfHorizOp, file
contrib/llvm/lib/Target/X86/X86ISelLowering.cpp, line 33661' when
building the devel/llvm90 port with CPUTYPE=haswell.

PR:		240759
2019-09-23 17:05:46 +00:00
Dimitry Andric
6d3bb28257 Pull in r372513 from upstream lld trunk (by Simon Atanasyan):
[mips] Deduce MIPS specific ELF header flags from `emulation`

  In case of linking binary blobs which do not have any ELF headers, we
  can deduce MIPS ABI ELF header flags from an `emulation` option.

  Patch by Kyle Evans.

Requested by:	kevans :)
2019-09-22 17:31:27 +00:00
Dimitry Andric
8a4b4f9f2b Pull in r371557 from upstream clang trunk (by Richard Smith):
When evaluating a __builtin_constant_p conditional, always enter
  constant-folding mode regardless of the original evaluation mode.

  In order for this to be correct, we need to track whether we're
  checking for a potential constant expression or checking for
  undefined behavior separately from the evaluation mode enum, since we
  don't want to clobber those states when entering constant-folding
  mode.

This should fix "ld: error: undefined symbol: ix86_isa_flags" (and many
other symbol names) during the initial stages of the lang/gcc* ports.

The issue was that without optimization, the __builtin_constant_p()
expressions generated in gencondmd.c would emit references to global
variables that were undefined, such as ix86_isa_flags.

PR:		240629
2019-09-21 21:01:38 +00:00
Dimitry Andric
7dfde55afd Pull in r371066 from upstream clang trunk (by Justin Hibbits):
Add -m(no)-spe to clang

  Summary:
  r337347 added support for the Signal Processing Engine (SPE) to LLVM.
  This follows that up with the clang side.

  This adds -mspe and -mno-spe, to match GCC.

  Subscribers: nemanjai, kbarton, cfe-commits

  Differential Revision: https://reviews.llvm.org/D49754
2019-09-19 19:42:59 +00:00
Dimitry Andric
7fc776a827 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmp
release 9.0.0 r372316, and update version numbers.
2019-09-19 19:25:01 +00:00
Dimitry Andric
ceb19815c7 Revert commit from upstream llvm trunk (by Hans Wennborg):
Re-commit r357452 (take 3): "SimplifyCFG
  SinkCommonCodeFromPredecessors: Also sink function calls without used
  results (PR41259)"

  Third time's the charm.

  This was reverted in r363220 due to being suspected of an internal
  benchmark regression and a test failure, none of which turned out to
  be caused by this.

As reported in https://bugs.llvm.org/show_bug.cgi?id=43269, this causes
UNREACHABLE errors when compiling if_malo_pci.c for arm and aarch64.
2019-09-14 10:55:33 +00:00
Dimitry Andric
f993ed2fbd Merge ^/head r351732 through r352104. 2019-09-09 19:58:46 +00:00
Dimitry Andric
c0e18e70bd Target i586 by default on the i386 architecture, since after upstream's
change https://reviews.llvm.org/rL356631 ("[X86] Add CMPXCHG8B feature
flag. Set it for all CPUs except i386/i486 including 'generic'. Disable
use of CMPXCHG8B when this flag isn't set"), clang now correctly emits
calls to __atomic_load_8, __atomic_store_8, etc. when targeting i486,
and this means we can no longer link most modern programs, because we do
not have a libatomic, nor support for atomic functions in libc.  See
also PR 230888, 220822, 233725, 234976, and more probably duplicates.

Note that in practice, clang has been incorrectly generating cmpxchg8b
instructions for years now, when targeting i486.  So de facto nothing
really changes by doing this.
2019-09-08 10:31:34 +00:00
Dimitry Andric
e2d4fd9739 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmp
release_90 branch r371301, and update version numbers.
2019-09-07 12:31:36 +00:00
Dimitry Andric
617ea2e6c8 Pull in r370426 from upstream llvm trunk (by Fāng-ruì Sòng):
[PPC32] Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO

  Unlike ppc64, which has ADDISgotTprelHA+LDgotTprelL pairs, ppc32 just
  uses LDgotTprelL32, so it does not make lots of sense to use _LO
  without a paired _HA.

  Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO to match GCC, and
  get better linker relocation check. Note, R_PPC_GOT_TPREL16_{HA,LO}
  don't have good linker support:

  (a) lld does not support R_PPC_GOT_TPREL16_{HA,LO}.
  (b) Top of tree ld.bfd does not support R_PPC_GOT_REL16_HA
      Initial-Exec -> Local-Exec relaxation:

    // a.o
    addis 3, 3, tsd_tls@got@tprel@ha
    lwz 3, tsd_tls@got@tprel@l(3)
    add 3, 3, tsd_tls@tls
    // b.o
    .section .tdata,"awT"; .globl tsd_tls; tsd_tls:

    // ld/ld-new a.o b.o
    internal error, aborting at ../../bfd/elf32-ppc.c:7952 in
    ppc_elf_relocate_section

  Reviewed By: adalava

  Differential Revision: https://reviews.llvm.org/D66925

This allows use of LLD for linking 32-bit static binaries on
FreeBSD/powerpc.

Submitted by:	Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>
2019-09-07 12:23:57 +00:00
Dimitry Andric
211f2e5c6b Pull in r371111 from upstream llvm trunk (by Eli Friedman):
[IfConversion] Fix diamond conversion with unanalyzable branches.

  The code was incorrectly counting the number of identical
  instructions, and therefore tried to predicate an instruction which
  should not have been predicated.  This could have various effects: a
  compiler crash, an assembler failure, a miscompile, or just
  generating an extra, unnecessary instruction.

  Instead of depending on TargetInstrInfo::removeBranch, which only
  works on analyzable branches, just remove all branch instructions.

  Fixes https://bugs.llvm.org/show_bug.cgi?id=43121 and
  https://bugs.llvm.org/show_bug.cgi?id=41121 .

  Differential Revision: https://reviews.llvm.org/D67203

This should fix "Unable to predicate BX killed renamable $r0" errors
when building the lang/spidermonkey170 and lang/spidermonkey38 ports for
armv7 and armv6.

PR:		236567
MFC after:	3 days
2019-09-06 16:06:37 +00:00
Dimitry Andric
24ea14660b Pull in r369828 from upstream lld trunk (by Fāng-ruì Sòng):
[ELF] Align the first section of a PT_LOAD even if its type is
  SHT_NOBITS

  Reported at https://reviews.llvm.org/D64930#1642223

  If the only section of a PT_LOAD is a SHT_NOBITS section (e.g. .bss),
  we may not align its sh_offset. p_offset of the PT_LOAD will be set
  to sh_offset, and we will get p_offset!=p_vaddr (mod p_align).  If
  such executable is mapped by the Linux kernel, it will segfault.

  After D64906, this may happen the non-linker script case.

  The linker script case has had this issue for a long time.  This was
  fixed by rL321657 (but the test linkerscript/nobits-offset.s failed
  to test a SHT_NOBITS section), but broken by rL345154.

  Reviewed By: peter.smith

  Differential Revision: https://reviews.llvm.org/D66658

Pull in r371013 from upstream lld trunk (by Rui Ueyama):

  Align output segments correctly

  Previously, segments were aligned according to their first section's
  alignment requirements. That was not correct, but segments are also
  aligned to a page boundary, and a page boundary is usually much
  larger than a section alignment requirement, so no one noticed this
  bug before.

  Now, lld has --nmagic option which sets maxPageSize to 1 to
  effectively disable page alignment, which reveals the issue.

  Fixes https://bugs.llvm.org/show_bug.cgi?id=43212

  Differential Revision: https://reviews.llvm.org/D67152

Together, these should ensure gpboot.out gets a correctly aligned offset
for its .rodata section, and fix "layout constraint violation" errors
from objcopy.
2019-09-05 17:53:41 +00:00
Dimitry Andric
c5c3ba6b43 Merge ^/head r351317 through r351731. 2019-09-03 05:58:43 +00:00
Dimitry Andric
6a82ac86f0 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmp
release_90 branch r370514, and update version numbers.
2019-09-02 17:55:39 +00:00
Dimitry Andric
22f75ae738 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmp
release_90 branch r369369, and update version numbers.
2019-09-02 17:32:57 +00:00
Ed Maste
aebac09b6f 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).
2019-09-01 16:50:34 +00:00
Dimitry Andric
5c1533a86d Disable UniversalMachO support in lldb's SystemInitializerFull.cpp,
since we do not need it.
2019-08-26 20:56:16 +00:00
Dimitry Andric
1f1d86b2b3 Update FREEBSD-Xlist for lldb. 2019-08-25 20:36:52 +00:00
Dimitry Andric
1771245355 Merge missed sources for lldb-specific TableGen tool. 2019-08-25 20:36:02 +00:00
Dimitry Andric
580d4aa65a Merge lldb trunk r366426, resolve conflicts, and update FREEBSD-Xlist. 2019-08-22 19:14:02 +00:00
Dimitry Andric
22d1794578 Merge lld trunk r366426, and resolve conflicts. 2019-08-21 20:44:42 +00:00
Dimitry Andric
e123fc8fd8 Merge clang trunk r366426, resolve conflicts, and update FREEBSD-Xlist. 2019-08-21 19:57:54 +00:00
Dimitry Andric
54db30ce18 Merge llvm trunk r366426, resolve conflicts, and update FREEBSD-Xlist. 2019-08-21 18:13:02 +00:00
Leandro Lupori
1153929465 [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
2019-07-31 16:22:05 +00:00
Dimitry Andric
ba9b2ede8a Pull in r366369 from upstream llvm trunk (by Francis Visoiu Mistrih):
[CodeGen][NFC] Simplify checks for stack protector index checking

  Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex()
  >= 0`.

Pull in r366371 from upstream llvm trunk (by Francis Visoiu Mistrih):

  [PEI] Don't re-allocate a pre-allocated stack protector slot

  The LocalStackSlotPass pre-allocates a stack protector and makes sure
  that it comes before the local variables on the stack.

  We need to make sure that later during PEI we don't re-allocate a new
  stack protector slot. If that happens, the new stack protector slot
  will end up being **after** the local variables that it should be
  protecting.

  Therefore, we would have two slots assigned for two different stack
  protectors, one at the top of the stack, and one at the bottom. Since
  PEI will overwrite the assigned slot for the stack protector, the
  load that is used to compare the value of the stack protector will
  use the slot assigned by PEI, which is wrong.

  For this, we need to check if the object is pre-allocated, and re-use
  that pre-allocated slot.

  Differential Revision: https://reviews.llvm.org/D64757

Pull in r367068 from upstream llvm trunk (by Francis Visoiu Mistrih):

  [CodeGen] Don't resolve the stack protector frame accesses until PEI

  Currently, stack protector loads and stores are resolved during
  LocalStackSlotAllocation (if the pass needs to run). When this is the
  case, the base register assigned to the frame access is going to be
  one of the vregs created during LocalStackSlotAllocation. This means
  that we are keeping a pointer to the stack protector slot, and we're
  using this pointer to load and store to it.

  In case register pressure goes up, we may end up spilling this
  pointer to the stack, which can be a security concern.

  Instead, leave it to PEI to resolve the frame accesses. In order to
  do that, we make all stack protector accesses go through frame index
  operands, then PEI will resolve this using an offset from sp/fp/bp.

  Differential Revision: https://reviews.llvm.org/D64759

Together, these fix a issue where the stack protection feature in LLVM's
ARM backend can be rendered ineffective when the stack protector slot is
re-allocated so that it appears after the local variables that it is
meant to protect, leaving the function potentially vulnerable to a
stack-based buffer overflow.

Reported by:	andrew
Security:	https://kb.cert.org/vuls/id/129209/
MFC after:	3 days
2019-07-26 18:49:20 +00:00
Dimitry Andric
87c8ef55c3 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
8.0.1 final release r366581.  The only functional change is a fix for a
mismerge of upstream r360816, which properly restores the r2 register
when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337).

Relnotes:	yes
PR:		236062
MFC after:	3 days
X-MFC-With:	r349004
2019-07-20 15:26:21 +00:00
Dimitry Andric
f7e8f5d439 Pull in r365760 from upstream lld trunk (by Fangrui Song):
[ELF] Handle non-glob patterns before glob patterns in version
  scripts & fix a corner case of --dynamic-list

  This fixes PR38549, which is silently accepted by ld.bfd.
  This seems correct because it makes sense to let non-glob patterns
  take precedence over glob patterns.

  lld issues an error because
  `assignWildcardVersion(ver, VER_NDX_LOCAL);` is processed before
  `assignExactVersion(ver, v.id, v.name);`.

  Move all assignWildcardVersion() calls after assignExactVersion()
  calls to fix this.

  Also, move handleDynamicList() to the bottom. computeBinding() called
  by includeInDynsym() has this cryptic rule:

      if (versionId == VER_NDX_LOCAL && isDefined() && !isPreemptible)
	return STB_LOCAL;

  Before the change:

  * foo's version is set to VER_NDX_LOCAL due to `local: *`
  * handleDynamicList() is called
    - foo.computeBinding() is STB_LOCAL
    - foo.includeInDynsym() is false
    - foo.isPreemptible is not set (wrong)
  * foo's version is set to V1

  After the change:

  * foo's version is set to VER_NDX_LOCAL due to `local: *`
  * foo's version is set to V1
  * handleDynamicList() is called
    - foo.computeBinding() is STB_GLOBAL
    - foo.includeInDynsym() is true
    - foo.isPreemptible is set (correct)

  Reviewed By: ruiu

  Differential Revision: https://reviews.llvm.org/D64550

This makes it longer necessary to patch the version scripts for the
samba ports, to avoid "duplicate symbol 'pdb_search_init' in version
script" errors.

PR:		230602
MFC after:	3 days
2019-07-13 15:04:30 +00:00
Dimitry Andric
128c495e50 Apply a workaround to be able to build clang 8.0.0 headers with clang
3.4.1, which is still in the stable/10 branch.

It looks like clang 3.4.1 implements static_asserts by instantiating a
temporary static object, and if those are in an anonymous union, it
results in "error: anonymous union can only contain non-static data
members".

To work around this implementation limitation, move the static_asserts
in question out of the anonymous unions.

This should make building the latest stable/11 from stable/10 possible
again.

Reported by:	Mike Tancsa <mike@sentex.net>
MFC after:	3 days
2019-07-10 05:57:37 +00:00
Dimitry Andric
ec38f4f941 Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r364487
(effectively, 8.0.1 rc3).  The 8.0.1 release will most likely
have no further changes.

MFC after:	1 week
X-MFC-With:	r349004
2019-07-06 18:02:29 +00:00
Dimitry Andric
d80439b9b0 Pull in r360968 from upstream llvm trunk (by Philip Reames):
Clarify comments on helpers used by LFTR [NFC]

  I'm slowly wrapping my head around this code, and am making comment
  improvements where I can.

Pull in r360972 from upstream llvm trunk (by Philip Reames):

  [LFTR] Factor out a helper function for readability purpose [NFC]

Pull in r360976 from upstream llvm trunk (by Philip Reames):

  [IndVars] Don't reimplement Loop::isLoopInvariant [NFC]

  Using dominance vs a set membership check is indistinguishable from a
  compile time perspective, and the two queries return equivelent
  results.  Simplify code by using the existing function.

Pull in r360978 from upstream llvm trunk (by Philip Reames):

  [LFTR] Strengthen assertions in genLoopLimit [NFCI]

Pull in r362292 from upstream llvm trunk (by Nikita Popov):

  [IndVarSimplify] Fixup nowrap flags during LFTR (PR31181)

  Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix
  for LFTR poison handling issues in general.

  When LFTR moves a condition from pre-inc to post-inc, it may now
  depend on value that is poison due to nowrap flags. To avoid this, we
  clear any nowrap flag that SCEV cannot prove for the post-inc addrec.

  Additionally, LFTR may switch to a different IV that is dynamically
  dead and as such may be arbitrarily poison. This patch will correct
  nowrap flags in some but not all cases where this happens. This is
  related to the adoption of IR nowrap flags for the pre-inc addrec.
  (See some of the switch_to_different_iv tests, where flags are not
  dropped or insufficiently dropped.)

  Finally, there are likely similar issues with the handling of GEP
  inbounds, but we don't have a test case for this yet.

  Differential Revision: https://reviews.llvm.org/D60935

Pull in r362971 from upstream llvm trunk (by Philip Reames):

  Prepare for multi-exit LFTR [NFC]

  This change does the plumbing to wire an ExitingBB parameter through
  the LFTR implementation, and reorganizes the code to work in terms of
  a set of individual loop exits. Most of it is fairly obvious, but
  there's one key complexity which makes it worthy of consideration.
  The actual multi-exit LFTR patch is in D62625 for context.

  Specifically, it turns out the existing code uses the backedge taken
  count from before a IV is widened. Oddly, we can end up with a
  different (more expensive, but semantically equivelent) BE count for
  the loop when requerying after widening.  For the nestedIV example
  from elim-extend, we end up with the following BE counts:
  BEFORE: (-2 + (-1 * %innercount) + %limit)
  AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)

  This is the only test in tree which seems sensitive to this
  difference. The actual result of using the wider BETC on this example
  is that we actually produce slightly better code. :)

  In review, we decided to accept that test change.  This patch is
  structured to preserve the old behavior, but a separate change will
  immediate follow with the behavior change.  (I wanted it separate for
  problem attribution purposes.)

  Differential Revision: https://reviews.llvm.org/D62880

Pull in r362975 from upstream llvm trunk (by Philip Reames):

  [LFTR] Use recomputed BE count

  This was discussed as part of D62880.  The basic thought is that
  computing BE taken count after widening should produce (on average)
  an equally good backedge taken count as the one before widening.
  Since there's only one test in the suite which is impacted by this
  change, and it's essentially equivelent codegen, that seems to be a
  reasonable assertion.  This change was separated from r362971 so that
  if this turns out to be problematic, the triggering piece is obvious
  and easily revertable.

  For the nestedIV example from elim-extend.ll, we end up with the
  following BE counts:
  BEFORE: (-2 + (-1 * %innercount) + %limit)
  AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)

  Note that before is an i32 type, and the after is an i64.  Truncating
  the i64 produces the i32.

Pull in r362980 from upstream llvm trunk (by Philip Reames):

  Factor out a helper function for readability and reuse in a future
  patch [NFC]

Pull in r363613 from upstream llvm trunk (by Philip Reames):

  Fix a bug w/inbounds invalidation in LFTR (recommit)

  Recommit r363289 with a bug fix for crash identified in pr42279.
  Issue was that a loop exit test does not have to be an icmp, leading
  to a null dereference crash when new logic was exercised for that
  case.  Test case previously committed in r363601.

  Original commit comment follows:

  This contains fixes for two cases where we might invalidate inbounds
  and leave it stale in the IR (a miscompile). Case 1 is when switching
  to an IV with no dynamically live uses, and case 2 is when doing
  pre-to-post conversion on the same pointer type IV.

  The basic scheme used is to prove that using the given IV (pre or
  post increment forms) would have to already trigger UB on the path to
  the test we're modifying. As such, our potential UB triggering use
  does not change the semantics of the original program.

  As was pointed out in the review thread by Nikita, this is defending
  against a separate issue from the hasConcreteDef case. This is about
  poison, that's about undef. Unfortunately, the two are different, see
  Nikita's comment for a fuller explanation, he explains it well.

  (Note: I'm going to address Nikita's last style comment in a separate
  commit just to minimize chance of subtle bugs being introduced due to
  typos.)

  Differential Revision: https://reviews.llvm.org/D62939

Pull in r363875 from upstream llvm trunk (by Philip Reames):

  [LFTR] Rename variable to minimize confusion [NFC]

  (Recommit of r363293 which was reverted when a dependent patch was.)

  As pointed out by Nikita in D62625, BackedgeTakenCount is generally
  used to refer to the backedge taken count of the loop. A conditional
  backedge taken count - one which only applies if a particular exit is
  taken - is called a ExitCount in SCEV code, so be consistent here.

Pull in r363877 from upstream llvm trunk (by Philip Reames):

  [LFTR] Stylistic cleanup as suggested in last review comment of
  D62939 [NFC]

  (Resumbit of r363292 which was reverted along w/an earlier patch)

Pull in r364346 from upstream llvm trunk (by Philip Reames):

  [LFTR] Adjust debug output to include extensions (if any)

Pull in r364693 from upstream llvm trunk (by Philip Reames):

  [IndVars] Remove a bit of manual constant folding [NFC]

  SCEV is more than capable of folding (add x, trunc(0)) to x.

Pull in r364709 from upstream llvm trunk (by Nikita Popov):

  [LFTR] Fix post-inc pointer IV with truncated exit count (PR41998)

  Fixes https://bugs.llvm.org/show_bug.cgi?id=41998. Usually when we
  have a truncated exit count we'll truncate the IV when comparing
  against the limit, in which case exit count overflow in post-inc form
  doesn't matter. However, for pointer IVs we don't do that, so we have
  to be careful about incrementing the IV in the wide type.

  I'm fixing this by removing the IVCount variable (which was ExitCount
  or ExitCount+1) and replacing it with a UsePostInc flag, and then
  moving the actual limit adjustment to the individual cases (which
  are: pointer IV where we add to the wide type, integer IV where we
  add to the narrow type, and constant integer IV where we add to the
  wide type).

  Differential Revision: https://reviews.llvm.org/D63686

Together, these should fix a hang when building the textproc/htmldoc
port, due to an incorrect loop optimization.

PR:		237515
MFC after:	1 week
2019-07-01 21:06:10 +00:00
Justin Hibbits
e861dab451 powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part)
Summary:
Toolchain follow-up to r349350.  LLVM patches will be submitted upstream for
9.0 as well.

The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it
cannot determine for certain that it needs Secure-PLT, and some binaries do
not compile in such a way to make it know to use Secure-PLT.

Reviewed By: nwhitehorn, bdragon, pfg
Differential Revision: https://reviews.freebsd.org/D20598
2019-06-25 02:35:22 +00:00
Dimitry Andric
efc5c4420a Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2).  The 8.0.1 release should follow this within a
week or so.

MFC after:	2 weeks
2019-06-12 21:10:37 +00:00
Dimitry Andric
0b30b98f26 Pull in r361696 from upstream llvm trunk (by Sanjay Patel):
[SelectionDAG] soften assertion when legalizing narrow vector FP ops

  The test based on PR42010:
  https://bugs.llvm.org/show_bug.cgi?id=42010

  ...may show an inaccuracy for PPC's target defs, but we should not be
  so aggressive with an assert here. There's no telling what
  out-of-tree targets look like.

This fixes an assertion when building the graphics/mesa-dri port for
PowerPC64.

Reported by:	Mark Millard <marklmi26-fbsd@yahoo.com>
PR:		238082
MFC after:	3 days
2019-05-26 15:44:58 +00:00
Dimitry Andric
6889af8687 Pull in r360099 from upstream llvm trunk (by Eli Friedman):
[ARM] Glue register copies to tail calls.

  This generally follows what other targets do. I don't completely
  understand why the special case for tail calls existed in the first
  place; even when the code was committed in r105413, call lowering
  didn't work in the way described in the comments.

  Stack protector lowering breaks if the register copies are not glued
  to a tail call: we have to insert the stack protector check before
  the tail call, and we choose the location based on the assumption
  that all physical register dependencies of a tail call are adjacent
  to the tail call. (See FindSplitPointForStackProtector.) This is sort
  of fragile, but I don't see any reason to break that assumption.

  I'm guessing nobody has seen this before just because it's hard to
  convince the scheduler to actually schedule the code in a way that
  breaks; even without the glue, the only computation that could
  actually be scheduled after the register copies is the computation of
  the call address, and the scheduler usually prefers to schedule that
  before the copies anyway.

  Fixes https://bugs.llvm.org/show_bug.cgi?id=41417

  Differential Revision: https://reviews.llvm.org/D60427

This should fix several instances of "Bad machine code: Using an
undefined physical register", when compiling ports such as
multimedia/vlc, audio/alsa-lib and devel/avro-c for armv6, with
-fstack-protector-strong.

Reported by:	jbeich
PR:		237074, 237783, 237784
MFC after:	3 days
2019-05-08 05:45:00 +00:00
Dimitry Andric
d705ee60a2 Pull in r357362 from upstream clang trunk (by David Chisnall):
[objc-gnustep] Use .init_array not .ctors when requested.

  This doesn't make a difference most of the time but FreeBSD/ARM
  doesn't run anything in the .ctors array.

This should help with updating the libobjc2 port for armv7.

Requested by:	theraven
Upstream PR:	https://github.com/gnustep/libobjc2/issues/83
MFC after:	3 days
2019-04-02 17:51:28 +00:00
Dimitry Andric
94e9dcf224 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
MFC after:	1 month
X-MFC-With:	r344779
2019-03-23 14:10:05 +00:00
Dimitry Andric
c3e6b9d390 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 after:	1 month
X-MFC-With:	r344779
2019-03-20 20:57:11 +00:00
Dimitry Andric
fb7e42b9fd 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 after:	1 month
X-MFC-With:	r344779
2019-03-20 19:18:26 +00:00
Dimitry Andric
2352f97079 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 after:	1 month
X-MFC-With:	r344779
2019-03-14 19:52:12 +00:00
Dimitry Andric
4cc79e8968 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 after:	1 month
X-MFC-With:	r344779
2019-03-12 18:19:44 +00:00
John Baldwin
c8a048a4a3 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
2019-03-12 16:41:17 +00:00
Dimitry Andric
e6ec44cf36 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 after:	1 month
X-MFC-With:	r344779
2019-03-11 19:15:57 +00:00
Dimitry Andric
66c4b4f1ce Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).
PR:		236062
MFC after:	1 month
X-MFC-With:	r344779
2019-03-11 18:56:04 +00:00
Dimitry Andric
30622d9f9e 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 after:	1 month
X-MFC-With:	r344779
2019-03-11 18:45:36 +00:00