This should fix the build after SVN r316178, which worked fine
on GCC 5.4, but failed on clang with errors like these:

MinGW.h:26:3: error: too few template arguments for class template 'StringSet'
  StringSet<> ExcludeSymbols;
  ^
lld/Common/LLVM.h:28:30: note: template is declared here
  template<typename T> class StringSet;

Don't forward declare and add the using directive in the main
lld/Common/LLVM.h header, but just qualify the class name
in MinGW.h instead.

llvm-svn: 316180

In function GetIntrinsic, not all types are covered. Types double and long long are missed, type long is wrongly treated same as int, it should be same as long long. These problems cause compiler crashes when compiling code in PR31161. This patch fixed the problem.

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

llvm-svn: 316179

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

llvm-svn: 316178

llvm-svn: 316177

Don't just test on 32-bit

llvm-svn: 316176

The cost of splitting a large vector instruction is not being taken into account by the getUserCost function. This was leading to some loops being over unrolled. The cost of a vector instruction is now being multiplied by the cost of the type legalization. This will return a more accurate cost.

Committing on behalf on Brad Nemanich (brad.nemanich@ibm.com)

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

llvm-svn: 316174

Summary:
We had a bug where if we had forked (in the ProcessLauncherPosixFork)
while another thread was writing a log message, we would deadlock. This
happened because the fork child inherited the locked log rwmutex, which
would never get unlocked. This meant the child got stuck trying to
disable all log channels.

The bug existed for a while but only started being apparent after
D37930, which started using ThreadLauncher (which uses logging) instead
of std::thread (which does not) for launching TaskPool threads.

The fix is to use pthread_atfork to make sure noone is writing a log
message while we are forking.

Reviewers: zturner, eugene, clayborg

Subscribers: lldb-commits

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

llvm-svn: 316173

Fix UB - signed integer overflow in regex. Thanks to Tim Shen for the patch. Reviewed as https://reviews.llvm.org/D39066

llvm-svn: 316172

llvm-svn: 316171

llvm-svn: 316170

Modify static_casts to not be tautological in some COFF i386
relocations.

Patch by Alex Langford!

llvm-svn: 316169

This is necessary to avoid an assertion in the included test case and similar 
assembler inputs.

llvm-svn: 316168

llvm-svn: 316167

As reported here https://bugs.llvm.org/show_bug.cgi?id=34988
[[nodiscard]] warnings were not being suppressed for
volatile-ref return values.

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

llvm-svn: 316166

llvm-svn: 316165

llvm-svn: 316164

llvm-svn: 316163

x86 has its own copy of integer absolute pattern matching to combine directly to a SUB+CMOV.

This patch removes the x86 combine and adds custom lowering support for ISD::ABS instead, allowing us to use the DAGCombiner version.

Additional test cases are already covered by iabs.ll (rL315706 and rL315711).

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

llvm-svn: 316162

llvm-svn: 316161

Before landing D38895

llvm-svn: 316160

While parameterising by XLen, also take the opportunity to clean up the 
formatting of the RISCV .td files.

This commit unifies the in-tree code with my patchset at 
<https://github.com/lowrisc/riscv-llvm>.

llvm-svn: 316159

llvm-svn: 316158

Patch by: Adam Balogh!

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

llvm-svn: 316157

The method IEEEFloat::convertFromStringSpecials() does not recognize
the "+Inf" and "-Inf" strings but these strings are printed for
the double Infinities by the IEEEFloat::toString().

This patch adds the "+Inf" and "-Inf" strings to the list of recognized
patterns in IEEEFloat::convertFromStringSpecials().

Reviewers: sberg, bogner, majnemer, timshen, rnk, skatkov, gottesmm, bkramer, scanon
Reviewed By: skatkov
Subscribers: apilipenko, reames, llvm-commits
Differential Revision: https://reviews.llvm.org/D38030

llvm-svn: 316156

llvm-svn: 316155

These test cases don't really add anything that isn't covered by other
tests as well, so we can safely remove them.

llvm-svn: 316154

It fails on some bots and now we know how to reproduce it.

llvm-svn: 316153

* Add missing override keyword.
* avoid unnecessary copy of std::string.

llvm-svn: 316152

llvm-svn: 316151

Original commit message:
"[cmake] Use find_package to discover zlib

This allows us to use standard cmake utilities to point to non-system zlib
locations.

Patch by Oksana Shadura and me (D39002)."

The new patch brings back the old behavior in the cases where find_package
cannot find zlib.

llvm-svn: 316150

These typos appeared in SVN r309226 and r309327.

llvm-svn: 316149

This more or less matches what GNU ld does.

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

llvm-svn: 316148

llvm-svn: 316147

llvm-svn: 316146

MergeFunctions uses (through FunctionComparator) a map of GlobalValues
to identifiers because it needs to compare functions and globals
do not have an inherent total order. Thus, FunctionComparator
(through GlobalNumberState) has a ValueMap<GlobalValue *>.

r315852 added a RAUW on globals that may have been previously
encountered by the FunctionComparator, which would replace
a GlobalValue * key with a ConstantExpr *, which is illegal.

This commit adjusts that code path to remove the function being
replaced from the ValueMap as well.

llvm-svn: 316145

llvm-svn: 316144

We were reading past the end of the buffer.

llvm-svn: 316143

LLVM checks if it is performing an in-source build and then stop the
build. However, this check is also triggered if LLVM is being build as
part of a parent project, which prevents the parent project itself from
using in-source builds. For example, CMake allows a parent project to
specify the output of its subproject:

add_subdirectory(llvm llvm_build)

This tells CMake to conduct an out-tree build of LLVM, which without
this patch will still fails because what is being tested is the parent
project, not LLVM. This is fixed by using the "CURRENT" variable, which
is only concerned by the CMakeLists that is actually bein processed at
the moment.

Tests:
Ran `make check-llvm`.

Patch by Henrique Jung <henriquenj_AT_gmail_DOT_com>

llvm-svn: 316142

LineCoverageIterator makes it easy for clients of coverage data to
determine line execution counts for a file or function. The coverage
iteration logic is tricky enough that it really pays not to have
multiple copies of it. Hopefully having just one implementation in LLVM
will make the iteration logic easier to test, reuse, and update.

This commit is NFC but I've added a unit test to go along with it just
because it's easy to do now.

llvm-svn: 316141

This is a simple code cleanup. It will facilitate moving
LineCoverageIterator to libCoverage.

llvm-svn: 316140