llvm-svn: 318444

lib/Target/ARC/ARCISelLowering.cpp:490:22: error: use of overloaded operator '<<' is ambiguous (with operand types 'llvm::raw_ostream' and 'llvm::MVT::SimpleValueType')
                     << RegVT.getSimpleVT().SimpleTy << "\n");
                     ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

llvm-svn: 318443

Currently, it prints the backward branch offset as unsigned value
like below:
       7:       7d 34 0b 00 00 00 00 00         if r4 s>= r3 goto 11 <LBB0_3>
       8:       b7 00 00 00 00 00 00 00         r0 = 0
LBB0_2:
       9:       07 00 00 00 01 00 00 00         r0 += 1
      ......
      17:       bf 31 00 00 00 00 00 00         r1 = r3
      18:       6d 32 f6 ff 00 00 00 00         if r2 s> r3 goto 65526 <LBB0_3+0x7FFB0>

The correct print insn 18 should be:
      18:       6d 32 f6 ff 00 00 00 00         if r2 s> r3 goto -10 <LBB0_2>

To provide better clarity and be consistent with kernel verifier output,
the insn 7 output is changed to the following with "+" added to
non-negative branch offset:
       7:       7d 34 0b 00 00 00 00 00         if r4 s>= r3 goto +11 <LBB0_3>

Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 318442

Also update a comment about the usage of RegisterTarget() that didn't mention
the new argument.

llvm-svn: 318441

Summary:
The MS ABI convention is that the 'this' pointer on entry is the address
of the vfptr that was used to make the virtual method call. In other
words, the pointer on entry always points to the base subobject that
introduced the virtual method. Consider this hierarchy:

  struct A { virtual void f() = 0; };
  struct B { virtual void g() = 0; };
  struct C : A, B {
    void f() override;
    void g() override;
  };

On entry to C::g, [ER]CX will contain the address of C's B subobject,
and C::g will have to subtract sizeof(A) to recover a pointer to C.

Before this change, we applied this adjustment in the prologue and
stored the new value into the "this" local variable alloca used for
debug info. However, MSVC does not do this, presumably because it is
often profitable to fold the adjustment into later field accesses. This
creates a problem, because the debugger expects the variable to be
unadjusted. Unfortunately, CodeView doesn't have anything like DWARF
expressions for computing variables that aren't in the program anymore,
so we have to declare 'this' to be the unadjusted value if we want the
debugger to see the right value.

This has the side benefit that, in optimized builds, the 'this' pointer
will usually be available on function entry because it doesn't require
any adjustment.

Reviewers: hans

Subscribers: aprantl, cfe-commits

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

llvm-svn: 318440

llvm-svn: 318439

Summary:
The patch seems to have turned some Android tests flaky. The reason is unclear.
This reverts D40100 in case we can't figure out what is happening.

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: srhines, kubamracek

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

llvm-svn: 318438

Reviewers: asb, apazos, mgrang

Reviewed By: mgrang

Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, llvm-commits

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

llvm-svn: 318437

This patch changes all i32 constant in store instruction to i64 with truncation, to increase the chance that the referenced constant can be shared with other i64 constant.

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

llvm-svn: 318436

This was reverted due to some failures on specific darwin buildbots,
the issue being that the new lit configuration was not setting the
SDKROOT environment variable.  We've tested a fix locally and confirmed
that it works, so this patch resubmits everything with the fix
applied.

llvm-svn: 318435

directive.

Added missed support for cancelling of target parallel for construct.

llvm-svn: 318434

Summary:
This change introduces a `DynamicSymbols` field to the ELF specific YAML
supported by `yaml2obj` and `obj2yaml`. This grouping of symbols provides a way
to represent ELF dynamic symbols. The `DynamicSymbols` structure is identical to
the existing `Symbols`.

Reviewers: compnerd, jakehehrlich, silvas

Reviewed By: silvas

Subscribers: silvas, jakehehrlich, llvm-commits

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

llvm-svn: 318433

llvm-svn: 318432

Summary:
Reuse the existing code for FreeBSD that is compatible with NetBSD.

Add NetBSD support in tests: tls_race.cc and tls_race2.cc.

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, dvyukov, vitalybuka, kcc, eugenis

Reviewed By: dvyukov

Subscribers: srhines, emaste, kubamracek, llvm-commits, #sanitizers

Tags: #sanitizers

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

llvm-svn: 318431

Also, increase test diversity (and show another bug) by varying the types.

llvm-svn: 318430

The objective is to remove it completelly.

This first patch removes the last use outside dsymutil.cpp and makes
it static.

llvm-svn: 318429

Summary:
This change fixes a bug where `obj2yaml` can in some cases produce YAML that
causes `yaml2obj` to error.

The ELF YAML document structure has a `Sections` mapping, which contains three
mappings, all of which are optional: `Local`, `Global`, and `Weak.` Any one of
these can be missing, but if all three are missing, then `yaml2obj` errors. This
change allows YAML input for cases like this one.

I have tested this with check-llvm and check-lld, and all tests passed.

This change is the result of test failures while working on D39582, which
introduces a `DynamicSymbols` mapping, which will be empty at times.

Reviewers: compnerd, jakehehrlich, silvas, kledzik, mehdi_amini, pcc

Reviewed By: compnerd

Subscribers: silvas, llvm-commits

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

llvm-svn: 318428

llvm-svn: 318427

Commit r318397 fixed the cache pruning interval which broke this test
as it was assuming that the cache pruning was always being
performed. Explicitly set prune interval to 0s to ensure this.

llvm-svn: 318426

llvm-svn: 318425

Fixed up to use a class for the commands, renamed the commands and added a way to just dump the compile unit full paths and optionally their support files with the new "dump-files"command.

llvm-svn: 318424

llvm-svn: 318423

This is required by the Asan run-time.

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

llvm-svn: 318422

The requirement is that shadow memory must be aligned to page
boundaries (4k in this case).  Use a closed form equation that always
satisfies this requirement.

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

llvm-svn: 318421

llvm-svn: 318420

This reverts commit r318397.

It broke tools/gold/X86/cache.ll.

llvm-svn: 318419

Also, remove some unnecessary bits. I don't think we need fcmp in any test here either?

llvm-svn: 318418

llvm-svn: 318417

llvm-svn: 318416

Summary:
There is a potential use-after-free bug in Scop::buildSchedule(Region *,
LoopStackTy &, LoopInfo &).  Before, we took a reference to LoopStack.back()
which is a use after free, since back is popped off further below. This didn't
crash before by pure chance, since LoopStack is actually a vector, and the
memory isn't freed upon pop. I turned this into an iterator-based algorithm.

Reviewers: grosser, bollu, Meinersbur

Reviewed By: Meinersbur

Subscribers: llvm-commits, pollydev

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

llvm-svn: 318415

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

llvm-svn: 318414

llvm.invariant.group.barrier may accept pointers to arbitrary address space.

This patch let it accept pointers to i8 in any address space and returns
pointer to i8 in the same address space.

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

llvm-svn: 318413

Reviewers: klimek, bkramer, sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

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

llvm-svn: 318412

Summary:
These preambles are built by ASTUnit and clangd. Previously, preambles
were always stored on disk.

In-memory preambles are routed back to the compiler as virtual files in
a custom VFS.

Interface of ASTUnit does not allow to use in-memory preambles, as
ASTUnit::CodeComplete receives FileManager as a parameter, so we can't
change VFS used by the compiler inside the CodeComplete method.

A follow-up commit will update clangd in clang-tools-extra to use
in-memory preambles.

Reviewers: klimek, sammccall, bkramer

Reviewed By: klimek

Subscribers: ioeric, cfe-commits

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

llvm-svn: 318411

Summary:
Recent Bionic have a slew of `async_safe_*` logging functions that are
basically the liblog ones but included within the libc. They have the advantage
of not allocating memory. `async_safe_write_log` does no formatting and is
likely the best candidate for logging.

Use a weak definition to try and use it. Also, avoid API level checks (as
the toolchain is compiled at a rather low API level) for `__android_log_write`
in favor of a weak definition as well.

Keep the fallback to `syslog` if nothing else was found.

I tried to overhaul the code block to only have a single #if SANITIZER_ANDROID
but I am not particularly attached to the form. LMKWYT.

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: srhines, kubamracek, llvm-commits

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

llvm-svn: 318410

Add correct library dependence.

llvm-svn: 318409

llvm-svn: 318408

This is to be able to reuse them in the llvm-opt-fuzzer.

llvm-svn: 318407

The extra comma meant it wasn't correctly checking that we weren't getting an
extra getelementptr.

llvm-svn: 318406

      // trunc (binop X, C) --> binop (trunc X, C')
      // trunc (binop (ext X), Y) --> binop X, (trunc Y)

I'm grouping sub with the other binops  because that makes the code simpler
and the transforms are valid:
https://rise4fun.com/Alive/UeF
...so even though we don't expect a sub with constant Op1 or any of the
other opcodes with constant Op0 due to canonicalization rules, we might as
well handle those situations if non-canonical code somehow reaches this
point (it should just make instcombine more efficient in reaching its
end goal).

This should solve the problem that later manifests in the vectorizers in 
PR35295:
https://bugs.llvm.org/show_bug.cgi?id=35295

llvm-svn: 318404