Besides the unsightly print-out, it was causing some buildbots to fail,
e.g. http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/9311

llvm-svn: 321711

Summary: This patch enables folding following expressions under -ffast-math flag: exp(log(x)) -> x, exp2(log2(x)) -> x, log(exp(x)) -> x, log2(exp2(x)) -> x

Reviewers: spatel, hfinkel, davide

Reviewed By: spatel, hfinkel, davide

Subscribers: scanon, llvm-commits

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

llvm-svn: 321710

This one was rolled back as follow-up to the failing commit.
Second try.

For the function declaration

auto foo5(Foo) -> Foo;
the parameter tokens were mapped to cursors representing the
FunctionDecl:

Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
Punctuation: ";" [1:19 - 1:20]

Fix this by ensuring that the trailing return type is not visited as
first.

Patch by Nikolai Kosjar.

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

llvm-svn: 321709

This broke test/Index/opencl-types.cl on several buildbots:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/3294
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/6498
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/5239

> [libclang] Support querying whether a declaration is invalid
>
> This is useful for e.g. highlighting purposes in an IDE.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40072

Also reverting follow-ups that otherwise caused conflicts for the
revert:

r321700 "Fix line endings."
r321701 "Fix more line endings."

r321698 "[libclang] Fix cursors for functions with trailing return type"
> For the function declaration
>
> auto foo5(Foo) -> Foo;
> the parameter tokens were mapped to cursors representing the
> FunctionDecl:
>
> Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
> Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
> Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
> Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
> Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
> Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
> Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
> Punctuation: ";" [1:19 - 1:20]
>
> Fix this by ensuring that the trailing return type is not visited as
> first.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40561

llvm-svn: 321708

After D41349, we can now directly access MCSubtargetInfo from 
createARM*AsmBackend. This patch makes use of this, avoiding the need to 
create a fresh MCSubtargetInfo (which was previously always done with a blank 
CPU and feature string). Given the total size of the change remains pretty 
tiny and we're removing the old explicit destructor, I changed the STI field 
to a reference rather than a pointer.

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

llvm-svn: 321707

llvm-svn: 321706

llvm-svn: 321705

This change deals with intrinsics with multiple outputs, for example load
instrinsic with address updated.

DAG selection for Instrinsics could be done either through source code or
tablegen. Handling all intrinsics in source code would introduce a huge chunk
of repetitive code if we have a large number of intrinsic that return multiple
values (see NVPTX as an example). While intrinsic class in tablegen supports
multiple outputs, tablegen only supports Intrinsics with zero or one output on
TreePattern. This appears to be a simple bug in tablegen that is fixed by this
change.

For Intrinsics defined as:

  def int_xxx_load_addr_updated: Intrinsic<[llvm_i32_ty, llvm_ptr_ty], [llvm_ptr_ty, llvm_i32_ty], []>;

Instruction will be defined as:

  def L32_X: Inst<(outs reg:$d1, reg:$d2), (ins reg:$s1, reg:$s2), "ld32_x $d1, $d2, $s2", [(set i32:$d1, i32:$d2, (int_xxx_load_addr_updated i32:$s1, i32:$s2))]>;

Patch by Wenbo Sun, thanks!

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

llvm-svn: 321704

Summary:
gcov / gcda-based profiling crashes when shared libraries are unloaded

Patch by Benoit Belley and test by Marco Castelluccio for Firefox

See https://bugs.llvm.org/show_bug.cgi?id=27224 & https://bugzilla.mozilla.org/show_bug.cgi?id=1401230

Reviewers: davidxl, rnk, void

Subscribers: jessicah, marco-c, belleyb, cfe-commits

Tags: #clang

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

llvm-svn: 321703

Summary: Fixes https://bugs.llvm.org/show_bug.cgi?id=35464.

Reviewers: zturner, rnk, void

Subscribers: sylvestre.ledru, llvm-commits, #sanitizers

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

llvm-svn: 321702

llvm-svn: 321701

llvm-svn: 321700

Summary:
Add a register class for SVE predicate operands that can only be p0-p7 (as opposed to p0-p15)

Patch [1/3] in a series to add predicated ADD/SUB instructions for SVE.

Reviewers: rengolin, mcrosier, evandro, fhahn, echristo, olista01, SjoerdMeijer, javed.absar

Reviewed By: fhahn

Subscribers: aemerson, javed.absar, tschuett, kristof.beyls, llvm-commits

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

llvm-svn: 321699

For the function declaration

auto foo5(Foo) -> Foo;
the parameter tokens were mapped to cursors representing the
FunctionDecl:

Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
Punctuation: ";" [1:19 - 1:20]

Fix this by ensuring that the trailing return type is not visited as
first.

Patch by Nikolai Kosjar.

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

llvm-svn: 321698

This is useful for e.g. highlighting purposes in an IDE.

Patch by Nikolai Kosjar.

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

llvm-svn: 321697

As experimental backends, I didn't have them configured to build in my local 
build config.

llvm-svn: 321696

This is the follow up patch for rL319881 which introduced
the function but did not put it into .exports file.

llvm-svn: 321695

TargetRegistryInfo::createMCAsmBackend no longer takes a TheTriple parameter. 
The majory of the TargetRegistryInfo::create* functions have no or very 
limitied per-parameter doc comments, and adding a comment for the 
MCSubtargetInfo, MCRegisterInfo and MCTargetOptions parameters seems like it 
would add no real value beyond reading the function signature. As such, I've 
just deleted the doc comment for TheTriple.

llvm-svn: 321694

llvm-svn: 321693

Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend. 
D20830 threaded an MCSubtargetInfo reference through 
MCAsmBackend::relaxInstruction, but this isn't the only function that would 
benefit from access. This patch removes the Triple and CPUString arguments 
from createMCAsmBackend and replaces them with MCSubtargetInfo.

This patch just changes the interface without making any intentional 
functional changes. Once in, several cleanups are possible:
* Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend
* Support 16-bit instructions when valid in MipsAsmBackend::writeNopData
* Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl
* Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221)

This change initially exposed PR35686, which has since been resolved in r321026.

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

llvm-svn: 321692

Summary:
The diagnostic was mostly introduced in D38101 by me, as a reaction to wasting a lot of time, see [[ https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171009/206427.html | mail ]].
However, the diagnostic is pretty dumb. While it works with no false-positives,
there are some questionable cases that are diagnosed when one would argue that they should not be.

The common complaint is that it diagnoses the comparisons between an `int` and
`long` when compiling for a 32-bit target as tautological, but not when
compiling for 64-bit targets. The underlying problem is obvious: data model.
In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are
64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer are 32-bit).

I.e. the common pattern is: (pseudocode)
```
#include <limits>
#include <cstdint>
int main() {
  using T1 = long;
  using T2 = int;

  T1 r;
  if (r < std::numeric_limits<T2>::min()) {}
  if (r > std::numeric_limits<T2>::max()) {}
}
```
As an example, D39149 was trying to fix this diagnostic in libc++, and it was not well-received.

This *could* be "fixed", by changing the diagnostics logic to something like
`if the types of the values being compared are different, but are of the same size, then do diagnose`,
and i even attempted to do so in D39462, but as @rjmccall rightfully commented,
that implementation is incomplete to say the least.

So to stop causing trouble, and avoid contaminating upcoming release, lets do this workaround:
* move these three diags (`warn_unsigned_always_true_comparison`, `warn_unsigned_enum_always_true_comparison`, `warn_tautological_constant_compare`) into it's own `-Wtautological-constant-in-range-compare`
* Disable them by default
* Make them part of `-Wextra`
* Additionally, give `warn_tautological_constant_compare` it's own flag `-Wtautological-type-limit-compare`.
  I'm not happy about that name, but i can't come up with anything better.

This way all three of them can be enabled/disabled either altogether, or one-by-one.

Reviewers: aaron.ballman, rsmith, smeenai, rjmccall, rnk, mclow.lists, dim

Reviewed By: aaron.ballman, rsmith, dim

Subscribers: thakis, compnerd, mehdi_amini, dim, hans, cfe-commits, rjmccall

Tags: #clang

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

llvm-svn: 321691

Previously the code for handling G_SMULO didn't properly check for the signed
multiply overflow, instead treating it the same as the unsigned G_UMULO.

Fixes PR35800.

llvm-svn: 321690

llvm-svn: 321689

llvm-svn: 321688

llvm-svn: 321687

variable is extern "C" in linkage calculations.

llvm-svn: 321686

llvm-svn: 321685

If a section is RW there is no reason to drop a relocation with a weak
undefined symbol.

llvm-svn: 321684

Fix and simplify handling of return type for (generic) lambda conversion function to function pointer.

Previously, we would:
 * compute the type of the conversion function and static invoker as a
   side-effect of template argument deduction for a conversion
 * re-compute the type as part of deduced return type deduction when building
   the conversion function itself

Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).

This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.

llvm-svn: 321683

This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.

Addresses rdar://36170689

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

llvm-svn: 321682

I have no clue how this was missed when symbol table support was added. This
change ensures that the visibility of symbols is preserved by default.

llvm-svn: 321681

Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.

It supports:

- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)

Patch by Leandro Lupori!

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

Now builds with LIBUNWIND_ENABLE_CROSS_UNWINDING=ON should
work.

llvm-svn: 321680

For builds that only target one architecture, this was required to
be an exact match, while it previously required the allocation to be
strictly larger than the largest concrete one. Requiring it to be
larger than on equal should be enough.

This makes it more straightforward to update _LIBUNWIND_CONTEXT_SIZE
and _LIBUNWIND_CURSOR_SIZE.

llvm-svn: 321679

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

llvm-svn: 321678

Summary:
This way new asan_device_setup, which knows about the quirks of
recent releases of Android, can be used with older ASan runtime
library (say, from an NDK release). The library is version locked to
the compiler, and is often hard or impossible to update.

Reviewers: vitalybuka

Subscribers: srhines, kubamracek, llvm-commits

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

llvm-svn: 321677

Fixes verifier errors with Windows EH and OpenMP, which injects a
terminate scope around parallel blocks.

Fixes PR35778

llvm-svn: 321676

This patch enables OMPT by default if version 50 or later is built and the config says, that OMPT will be supported.

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

llvm-svn: 321675

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

Change-Id: Ie3a405b28503ceae999f5f3ba07a68fa733a2400
llvm-svn: 321674

llvm-svn: 321673

This is part of solving PR35717:
https://bugs.llvm.org/show_bug.cgi?id=35717

The larger IR optimization is proposed in D41603, but we can show 
the improvement in ValueTracking using codegen tests because 
SelectionDAG creates min/max nodes based on ValueTracking. 

Any target with min/max ops should show wins here. I chose AArch64
vector ops because they're clean and uniform.

Some Alive proofs for the tests (can't put more than 2 tests in 1 
page currently because the web app says it's too long):
https://rise4fun.com/Alive/WRN
https://rise4fun.com/Alive/iPm
https://rise4fun.com/Alive/HmY
https://rise4fun.com/Alive/CNm
https://rise4fun.com/Alive/LYf

llvm-svn: 321672