It turns out we should not use the std::sort anymore.
r327219 added a new wrapper llvm::sort (D39245).
When EXPENSIVE_CHECKS is defined, it shuffles the
input container and that helps to find non-deterministic
ordering.

Patch changes code to use llvm::sort and std::stable_sort
instead of std::sort

Differential revision: https://reviews.llvm.org/D45969

llvm-svn: 330702

Our code for LazyObject and LazyArchive duplicates.

This patch extracts the common part to remove
the duplication.

Differential revision: https://reviews.llvm.org/D45516

llvm-svn: 330701

Summary:
The pass is supposed to scalarize such intrinsics if the target does not support
them natively, so if the scalarization does not happen instruction selection
crashes due to inability to lower these intrinsics.

Reviewers: andrew.w.kaylor, craig.topper

Reviewed By: andrew.w.kaylor

Subscribers: llvm-commits

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

llvm-svn: 330700

llvm-svn: 330699

By checking that none of the child loops contain a BB we make sure BBMap
contains the innermost loop defining BB. This invariant was violated in
LoopInterchange and got caught by this assertion.

Reviewers: chandlerc, mzolotukhin, sanjoy, mehdi_amini, efriedma

Reviewed By: efriedma

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

llvm-svn: 330698

Reviewers: fhahn, rengolin, samparker, SjoerdMeijer, t.p.northover, echristo, evandro, javed.absar

Reviewed By: rengolin

Subscribers: tschuett, kristof.beyls, llvm-commits

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

llvm-svn: 330697

Previously it would only accept a string as a GCC version if it had
either two components and no suffix, or three components with an
optional suffix.

Debian and ubuntu provided mingw compilers have lib/gcc/target entries
like "5.3-posix" and "5.3-win32". This doesn't try to make any specific
preference between them (other than lexical sorting of the suffix).

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

llvm-svn: 330696

llvm-svn: 330695

/usr/local/bin/ld.lld: error: undefined symbol: llvm::createAggressiveInstCombinerPass()
>>> referenced by cc1_main.cpp
>>>               tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o:(_GLOBAL__sub_I_cc1_main.cpp)

And so on

The bot coverage is clearly missing.

llvm-svn: 330694

/usr/local/bin/ld.lld: error: undefined symbol: llvm::createAggressiveInstCombinerPass()
>>> referenced by cc1_main.cpp
>>>               tools/clang/tools/driver/CMakeFiles/clang.dir/cc1_main.cpp.o:(_GLOBAL__sub_I_cc1_main.cpp)

And so on

The bot coverage is clearly missing.

llvm-svn: 330693

All attributes have a source range associated with it. However, implicit
attributes are added by the compiler, and not added because the user
wrote something in the input. So no token type should be set to
CXCursor_*Attr.

The problem was visible when a class gets marked by e.g.
MSInheritanceAttr, which has the full CXXRecordDecl's range as its
own range. The effect of marking that range as CXCursor_UnexposedAttr
was that all cursors for the record decl, including all child decls,
would become CXCursor_UnexposedAttr.

llvm-svn: 330692

Summary:
I am preparing a patch to the path function. While working on it, I
noticed that some of the areas are lacking test coverage (e.g. filename
and parent_path functions), so I add more tests to guard against
regressions there.

I have also found the failure messages hard to understand, so I rewrote
some existing test to give more actionable messages when they fail:
- for tests which run over multiple inputs, I use SCOPED_TRACE, to show
  which of the inputs caused the actual failure.
- for comparisons of vectors, I use gmock's container matchers, which
  will print out the full container contents (and the elements that
  differ) when they fail to match.

Reviewers: zturner, espindola

Subscribers: llvm-commits

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

llvm-svn: 330691

llvm-svn: 330690

llvm-svn: 330689

llvm-svn: 330688

It doesn't make sense to non-deterministically choose between
`CopyPart(..)` and `InsertPart(..)` when it is known that
`InsertPart(..)` will fail.

This upstream's a change from JFS solver's fork of LibFuzzer.

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

llvm-svn: 330687

Follow-up for r330685.

llvm-svn: 330686

Add explicit dependency on ObjcopyTableGen 
and rerun the tests on Windows. 
I will double-check the build bots 
and revert this commit if necessary.

llvm-svn: 330685

llvm-svn: 330684

llvm-svn: 330683

This encoding is recognized by the CPU, but the behavior is undefined. This makes the disassembler handle it correctly so we don't print bswapl with a 16-bit register.

llvm-svn: 330682

The unmasked versions already didn't have this restrction. I don't think gcc or icc limit these to 64-bit mode so we shouldn't either.

llvm-svn: 330681

This code path can very clearly be called in a context where we have
baselined all the cloned blocks to a particular loop and are trying to
handle nested subloops. There is no harm in this, so just relax the
assert. I've added a test case that will make sure we actually exercise
this code path.

llvm-svn: 330680

llvm-svn: 330679

llvm-svn: 330678

llvm-svn: 330677

llvm-svn: 330676

No functional change intended.

llvm-svn: 330675

llvm-svn: 330674

The test is apparently needed e.g. for check-cfi on Windows where we get
  'C:/b/slave/sanitizer-windows/build/./bin/clang.exe': command not found
without it.  Try to fix the problem that was fixed by r330672 by also checking
for isabs() instead.

llvm-svn: 330673

lit's util.which() would check if the passed-in path existed directly,
and if so return it as-is.  This is never the case when running llvm's, clang's,
or lld's tests normally.  But when running `./llvm-lit path/to/clang/test`
with a cwd of llvm-build/bin, this if would detect that clang exists at path
'clang' and return 'clang' as the discovered clang binary -- and then lit would
use the " clang " -> "*** Do not use 'clang' in tests, use '%clang'. ***"
substitution to replace that with a broken test.  By removing this early
return, lit ends up with the usual absolute path and everything works even
in this uncommon case.

llvm-svn: 330672

llvm-svn: 330671

llvm-svn: 330670

(notionally Scalar.h is part of libLLVMScalarOpts, so it shouldn't be
included by InstCombine which doesn't/shouldn't need to depend on
ScalarOpts)

llvm-svn: 330669

I just tried to copy what was done for regular InstCombine. Hopefully I didn't miss anything.

llvm-svn: 330668

I was reminded today that this patch got reverted in r301885. I can no
longer reproduce the failure that caused the revert locally (...almost
one year later), and the patch applied pretty cleanly, so I guess we'll
see if the bots still get angry about it.

The original breakage was InstSimplify complaining (in "assertion
failed" form) about getting passed some crazy IR when running `ninja
check-sanitizer`. I'm unable to find traces of what, exactly, said crazy
IR was. I suppose we'll find out pretty soon if that's still the case.
:)

Original commit:

  Author: gbiv
  Date: Mon May  1 18:12:08 2017
  New Revision: 301880

  URL: http://llvm.org/viewvc/llvm-project?rev=301880&view=rev
  Log:
  [InstSimplify] Handle selects of GEPs with 0 offset

  In particular (since it wouldn't fit nicely in the summary):
  (select (icmp eq V 0) P (getelementptr P V)) -> (getelementptr P V)

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

llvm-svn: 330667

There're issues with IFUNC support on other platforms.

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

llvm-svn: 330666

There're issues with IFUNC support on other platforms.

DIfferential Revision: https://reviews.llvm.org/D45840

llvm-svn: 330665

llvm-svn: 330664

[AggressiveInstCombine] Add library initializer routine for AggressiveInstCombine library. Use it in bugpoint and llvm-opt-fuzzer to match regular InstCombine.

This should make aggressive instcombine usable with these tools.

llvm-svn: 330663