llvm-svn: 353267

llvm-svn: 353266

DomTreeUpdater depends on headers from Analysis, but is in IR.  This is a
layering violation since Analysis depends on IR.  Relocate this code from IR
to Analysis to fix the layering violation.

llvm-svn: 353265

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

llvm-svn: 353264

The definition is harmful here as it suppresses R_PPC64_REL24 which is
supposed to follow R_PPC64_TLSLD.

llvm-svn: 353263

Summary:
R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error.

R_PPC64_GOT_TLSGD16_HA
R_PPC64_GOT_TLSGD16_LO
R_PPC64_TLSGD R_TLSDESC_CALL
R_PPC64_REL24 __tls_get_addr

Reviewers: ruiu, sfertile, syzaara, espindola

Reviewed By: sfertile

Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur

Tags: #llvm

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

llvm-svn: 353262

llvm-svn: 353261

Reviewers: tlively

Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, cfe-commits

Tags: #clang

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

llvm-svn: 353260

llvm-svn: 353259

llvm-svn: 353258

Thanks Jonas...  One more early continue and using
a range where we had an iterator.

NFC

llvm-svn: 353257

Summary:
Refactor the way /proc/self/maps entries are annotated to support most
(all?) posix platforms, with a special implementation for Android.
Extend the set of decorated Mmap* calls.

Replace shm_open with internal_open("/dev/shm/%s"). Shm_open is
problematic because it calls libc open() which may be intercepted.

Generic implementation has limits (max number of files under /dev/shm is
64K on my machine), which can be conceivably reached when sanitizing
multiple programs at once. Android implemenation is essentially free, and
enabled by default.

The test in sanitizer_common is copied to hwasan and not reused directly
because hwasan fails way too many common tests at the moment.

Reviewers: pcc, vitalybuka

Subscribers: srhines, kubamracek, jfb, llvm-commits, kcc

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

llvm-svn: 353255

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

llvm-svn: 353254

llvm-svn: 353251

In a previous patch, I made changes so that PDBs which were
generated on non-Windows platforms contained sensical paths
for the host.  While this is an esoteric use case, we need
it to be supported for certain cross compilation scenarios
especially with LLDB, which can debug things on non-Windows
platforms.

However, this regressed a case where you specify /PDBSOURCEPATH
and use a windows-style path.  Previously, we would still remove
dots and canonicalize slashes to backslashes, but since my
change intentionally tried to support non-backslash paths, this
was broken.

This patch fixes the situation by trying to guess which path
style the user is specifying when /PDBSOURCEPATH is passed.
It is intentionally conservative, erring on the side of a
Windows path style unless absolutely certain.  All dots are
removed and slashes canonicalized to whatever the deduced
path style is after appending the file path to the /PDBSOURCEPATH
argument.

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

llvm-svn: 353250

llvm-svn: 353249

Summary:
- Delete {} for one-line `let` statements
- Don't indent within `let` blocks
- Add comments after `let` block's closing braces

Reviewers: tlively

Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 353248

The assert added to EmitCall there was triggering in Windows Chromium
builds, due to a mismatch of the return type.

The MSVC constructor call extension (`this->Foo::Foo()`) was emitting
the constructor call from 'EmitCXXMemberOrOperatorMemberCallExpr' via
calling 'EmitCXXMemberOrOperatorCall', instead of
'EmitCXXConstructorCall'. On targets where HasThisReturn is true, that
was failing to set the proper return type in the call info.

Switching to calling EmitCXXConstructorCall also allowed removing some
code e.g. the trivial copy/move support, which is already handled in
EmitCXXConstructorCall.

Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=928861
Differential Revision: https://reviews.llvm.org/D57794

llvm-svn: 353246

Summary:
Use a small cache for Values tested by nonEscapingLocalObject().
Since the calls to PointerMayBeCaptured are fairly expensive, this saves
a good amount of compile time for anything relying heavily on
BasicAA.alias() calls.

This uses the same approach as the AliasCache, i.e. the cache is reset
after each alias() call. The cache is not used or updated by modRefInfo
calls since it's harder to know when to reset the cache.

Testcases that show improvements with this patch are too large to
include. Example compile time improvement: 7s to 6s.

Reviewers: chandlerc, sunfish

Subscribers: sanjoy, jlebar, llvm-commits

Tags: #llvm

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

llvm-svn: 353245

Not depending on //clang/lib/StaticAnalyzer/Core and
//clang/lib/StaticAnalyzer/Frontend causes a linker error even if
ClangSACheckers are not supported.

Undefined symbols for architecture x86_64:
  "clang::ento::CreateAnalysisConsumer(clang::CompilerInstance&)", referenced from:
      clang::tidy::ClangTidyASTConsumerFactory::CreateASTConsumer(
              clang::CompilerInstance&, llvm::StringRef)
          in libclangTidy.a(libclangTidy.ClangTidy.o)

Patch from Mirko Bonadei <mbonadei@webrtc.org>!

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

llvm-svn: 353244

An equivalent change was made to RemapPaths, but it needed to be made 
here as well.  Also added a test for this and made the setup a little
more complex to avoid false successes.

<rdar://problem/47642498>

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

llvm-svn: 353243

Resumes that are not reachable from a cleanup landing pad are considered
to be unreachable. It’s not safe to split them out.

rdar://47808235

llvm-svn: 353242

The existing scheme of class template static members for Name and
NameMutex is a bit verbose, involves global ctors (even if they're cheap
for string and mutex, still not entirely free), and (importantly/my
immediate motivation here) trips over a bug in LLVM's modules
implementation that's a bit involved (hmm, sounds like Mr. Smith has a
fix for the modules thing - but I'm still inclined to commit this patch
as general goodness).

llvm-svn: 353241

For global variables with unordered initialization that are instantiated
within a module, we previously did not emit the global (or its
initializer) at all unless it was used in the importing translation unit
(and sometimes not even then!), leading to misbehavior and link errors.

We now emit the initializer for an instantiated global variable with
unordered initialization with side-effects in a module into every
translation unit that imports the module. This is unfortunate, but
mostly matches the behavior of a non-modular compilation and seems to be
the best that we can reasonably do.

llvm-svn: 353240

llvm-svn: 353239

llvm-svn: 353238

A fallible iterator is one whose increment or decrement operations may fail.
This would usually be supported by replacing the ++ and -- operators with
methods that return error:

    class MyFallibleIterator {
    public:
      // ...
      Error inc();
      Errro dec();
      // ...
    };

The downside of this style is that it no longer conforms to the C++ iterator
concept, and can not make use of standard algorithms and features such as
range-based for loops.

The fallible_iterator wrapper takes an iterator written in the style above
and adapts it to (mostly) conform with the C++ iterator concept. It does this
by providing standard ++ and -- operator implementations, returning any errors
generated via a side channel (an Error reference passed into the wrapper at
construction time), and immediately jumping the iterator to a known 'end'
value upon error. It also marks the Error as checked any time an iterator is
compared with a known end value and found to be inequal, allowing early exit
from loops without redundant error checking*.

Usage looks like:

    MyFallibleIterator I = ..., E = ...;

    Error Err = Error::success();
    for (auto &Elem : make_fallible_range(I, E, Err)) {
      // Loop body is only entered when safe.

      // Early exits from loop body permitted without checking Err.
      if (SomeCondition)
        return;

    }
    if (Err)
      // Handle error.

* Since failure causes a fallible iterator to jump to end, testing that a
  fallible iterator is not an end value implicitly verifies that the error is a
  success value, and so is equivalent to an error check.

Reviewers: dblaikie, rupprecht

Subscribers: mgorny, dexonsmith, kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 353237

llvm-svn: 353236

As discussed in D53037, this can lead to worse codegen, and we
don't generally expect the backend to be able to optimize
arbitrary shuffles. If there's only one use of the 1st shuffle,
that means it's getting removed, so that should always be
safe.

llvm-svn: 353235

r353131 caused failures in v128.const test for clang-ppc64be-linux-lnt
and clang-s390x-linux bots. This temporarily disables that line until
it is fixed.

llvm-svn: 353234

As discussed in D53037, this transform can cause codegen problems
if the 1st shuffle has multiple uses.

llvm-svn: 353233

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

llvm-svn: 353232

When a framework with the same name is available at multiple framework
search paths, we use the first matching location. If a framework at this
location doesn't have all the headers, it can be confusing for
developers because they see only an error `'Foo/Foo.h' file not found`,
can find the complete framework with required header, and don't know the
incomplete framework was used instead.

Add a note explaining a framework without required header was found.
Also mention framework directory path to make it easier to find the
incomplete framework.

rdar://problem/39246514

Reviewers: arphaman, erik.pilkington, jkorous

Reviewed By: jkorous

Subscribers: jkorous, dexonsmith, cfe-commits

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

llvm-svn: 353231

Factored out the code for creating variable for profile file name to
a function.

llvm-svn: 353230

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

llvm-svn: 353229

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

llvm-svn: 353228

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

llvm-svn: 353227

llvm-svn: 353226

Change the format type of Dyn.SONameOffset to PRIx64 since it is a uint64_t.
The problem was detected on mips builds, where it was printing junk values
and causing test failure.

Patch by Milos Stojanovic.

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

llvm-svn: 353225

llvm-svn: 353224