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

llvm-svn: 301075

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

llvm-svn: 301074

llvm-svn: 301073

In dwo files the fixed offset can be used - if the dwos are linked into
a dwp, the dwo consumer must use the dwp tables to find out where the
original range of the debug_info was and resolve the "section relative"
value relative to that original range - effectively
avoiding/reimplementing the relocation handling.

llvm-svn: 301072

(though this seems like a "does this not crash" test - which isn't very
good. Should be fixed)

llvm-svn: 301071

The bug was introduced by r301018 "[InstCombine] fadd double (sitofp x), y check that the promotion is valid". The patch didn't expect that fadd can be on vectors not necessarily scalars. Add vector support along with the test.

llvm-svn: 301070

llvm-svn: 301069

Remove the unnecessary virtual dtor from the DIEUnit hierarchy (in favor of protected dtor in the base, final derived classes with public non-virtual dtors)

These objects are never polymorphically owned/destroyed, so the virtual
dtor was unnecessary.

llvm-svn: 301068

Removes Clang warning ThreadSanitizerRuntime.cpp:591:21: warning:
comparison of integers of different signs: 'int' and 'size_t' (aka
'unsigned long') [-Wsign-compare]

llvm-svn: 301067

llvm-svn: 301066

These were added in r301016, but they're failing, because
-fsanitize=cfi seemingly causes -flto=thin to emit raw bitcode objects,
rather than the mach-o-wrapped bitcode we emit with -flto=thin alone.

That causes all tests to fail with ld64 errors.

Filed PR32741.

llvm-svn: 301065

If a switch was in an unreachable block that branched
to a block with a phi, it would leave phis with missing
predecessors.

llvm-svn: 301064

Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.

By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.

The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.

llvm-svn: 301063

Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.

By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.

The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.

llvm-svn: 301062

llvm-svn: 301061

For std::isinf, the standard requires effectively calling isinf as
double from Libc for integral types. But integral types are never
infinite; we don't need to call Libc to return false.

Also short-circuit other functions where Libc won't have interesting
answers: signbit, fpclassify, isfinite, isnan, and isnormal.

I added correctness tests for integral types since we're no longer
deferring to Libc.

In review it was pointed out that in future revisions of the C++
standard we may add more types to std::is_arithmetic (e.g.,
std::is_fixed_point).  I'll leave it to a future commit to hack this to
allow using math functions on those.  We'll need to change things like
__libcpp_fpclassify anyway, so I'm not sure anything here would really
be future-proof.

https://reviews.llvm.org/D31561
rdar://problem/31361223

llvm-svn: 301060

llvm-svn: 301059

llvm-svn: 301058

The code assumed that when saving an additional CSR register
(ExtraCSSpill==true) we would have a free register throughout the
function. This was not true if this CSR register is also used to pass
values as in the swiftself case.

rdar://31451816

llvm-svn: 301057

This switches from the prototype syntax in P0273R0 ('module' and 'module
implementation') to the consensus syntax 'export module' and 'module'.

In passing, drop the "module declaration must be first" enforcement, since EWG
seems to have changed its mind on that.

llvm-svn: 301056

* Cover optional's emplace-from-initializer_list overload

* Verify that any::emplace and optional::emplace return a reference to the correct type even for throwing cases.

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

llvm-svn: 301055

There are two reasons why users might want to build libfuzzer:
- To fuzz LLVM itself
- To get the libFuzzer.a archive file, so that they can attach it to their code
This change always builds libfuzzer, and supports the second use case if the specified flag is set.

The point of this patch is to have something that can potentially be shipped with the compiler, and this also ensures that the version of libFuzzer is correct to use with that compiler.

Patch by George Karpenkov.

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

llvm-svn: 301054

APInt just got compare methods that return -1, 0, or 1 instead of just having ult/slt and eq.

This patch uses these methods to implement APSInt::compareValues so that we don't have to call do an equal comparison and then possibly a second less than comparison.

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

llvm-svn: 301053

[APSInt] Make use of APInt's recently acquired in place lshr and shl capabilities in APSInt's >>= and <<= operators.

APInt hasn't acquired an in place ashr yet, but hopefully soon.

llvm-svn: 301052

llvm-svn: 301051

llvm-svn: 301050

llvm-svn: 301049

Summary: Re-landing reverted D31995 with suppressions defined in D32303 and D32377.

Reviewers: eugenis

Subscribers: nemanjai, llvm-commits

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

llvm-svn: 301048

In addition to the original commit, tighten the condition for when to
pad empty functions to COFF Windows.  This avoids running into problems
when targeting e.g. Win32 AMDGPU, which caused test failures when this
was committed initially.

llvm-svn: 301047

llvm-svn: 301046

Summary: When using /msvclto, lld and MSVC's linker both do their own symbol resolution. This can cause them to select different archive members, which can result in undefined references. This change avoids that situation by extracting archive members that are selected by lld and passing those to link.exe before any archives, so that MSVC's uses those objects for symbol resolution instead of different archive members.

Reviewers: pcc, rnk, ruiu

Reviewed By: pcc

Subscribers: llvm-commits, mehdi_amini

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

llvm-svn: 301045

Fixes leaving intermediate flat addressing computations
where a GEP instruction's source is a constant expression.

Still leaves behind a trivial addrspacecast + gep pair that
instcombine is able to handle, which ideally could be folded
here directly.

llvm-svn: 301044

Summary: Refer to https://sourceware.org/bugzilla/show_bug.cgi?id=12650 for the context.

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 301043

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

llvm-svn: 301042

This broke almost all bots. Reverting while fixing.

llvm-svn: 301041

Empty functions can lead to duplicate entries in the Guard CF Function
Table of a binary due to multiple functions sharing the same RVA,
causing the kernel to refuse to load that binary.

We had a terrific bug due to this in Chromium.

It turns out we were already doing this for Mach-O in certain
situations. This patch expands the code for that in
AsmPrinter::EmitFunctionBody() and renames
TargetInstrInfo::getNoopForMachoTarget() to simply getNoop() since it
seems it was used for not just Mach-O anyway.

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

llvm-svn: 301040

https://reviews.llvm.org/D32371

llvm-svn: 301039

llvm-svn: 301038

Forgot a git add yesterday.

llvm-svn: 301037

Otherwise there's some mismatch, and we'll either form an illegal type or an
illegal node.

Thanks to Eli Friedman for pointing out the problem with my original solution.

llvm-svn: 301036