Noticed in D57514.

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

llvm-svn: 352922

The test seems to be failing because the module suppression file
contains a colon. I found that it was sufficient to just use the
basename of the suppression file.

While I was here, I noticed that we don't implement IsAbsolutePath for
Windows, so I added it.

llvm-svn: 352921

Prepare for future patch which affects codegen for calls to preemptible
functions.

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

llvm-svn: 352920

llvm-svn: 352919

llvm-svn: 352918

Run checks for Win32 as well.

llvm-svn: 352917

Summary:
Using realpath makes assumptions about build systems that do not always hold true. The debug binary referred to from the .gnu_debuglink should exist in the same directory (or in a .debug directory, etc.), but the files may only exist as symlinks to a differently named files elsewhere, and using realpath causes that lookup to fail.

This was added in r189250, and this is basically a revert + regression test case.

Reviewers: dblaikie, samsonov, jhenderson

Reviewed By: dblaikie

Subscribers: llvm-commits, hiraditya

Tags: #llvm

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

llvm-svn: 352916

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

llvm-svn: 352914

This cleans up all GetElementPtr creation in LLVM to explicitly pass a
value type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352913

This cleans up all LoadInst creation in LLVM to explicitly pass the
value type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352911

This cleans up all InvokeInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352910

This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352909

Run checks for Win64 as well.

llvm-svn: 352908

We'll need to do this eventually if we create an installable package.
For now, this lets me use the archives to build Android, whose build
system wants to copy the archives to another location.

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

llvm-svn: 352907

This patch implements parsing and sema for "omp declare mapper"
directive. User defined mapper, i.e., declare mapper directive, is a new
feature in OpenMP 5.0. It is introduced to extend existing map clauses
for the purpose of simplifying the copy of complex data structures
between host and device (i.e., deep copy). An example is shown below:

    struct S {  int len;  int *d; };
    #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper.

Contributed-by: Lingda Li <lildmh@gmail.com>

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

llvm-svn: 352906

Summary:
We currently have effectively 3 implementations of type_info: one for
the Microsoft ABI, one that does not assume that there's a unique copy
of each RTTI in a progran, and one that assumes a unique copy.

Those 3 implementations are entangled into the same class with nested
ifdefs, which makes it very difficult to understand. Furthermore, the
benefit of doing this is rather small since the code that is duplicated
across implementations is just a couple of trivial lines.

This patch stamps out the 3 versions of type_info explicitly to increase
readability. It also explains what's going on with short comments, because
it's far from obvious.

Reviewers: EricWF, mclow.lists

Subscribers: christof, jkorous, dexonsmith

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

llvm-svn: 352905

- If that operand is not ConstantInt, skip enabling TFE/LWE.

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

llvm-svn: 352904

These seem to only appear on the buildbot runner, and it looks like we
tried to suppress them, but it's not working. Not sure why.

llvm-svn: 352903

llvm-svn: 352902

This reverts commit 72c1213a5e901b80c0f1d2794e5088d7f71a3632.

llvm-svn: 352901

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

llvm-svn: 352900

libc++ has programmable ABI versioning controllable with the _LIBCPP_ABI_VERSION
macro.  Currently there are at least 3 settings used in real systems (1 as the
default, ndk1 for Anroid, Cr for Chromium).

Only the 1 and ndk1 cases were handled.  This change relaxes the check to allow
any ABI version.

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

llvm-svn: 352899

Background: At the moment, we record the AtomicOrdering of an access in the MMO, but also mark any atomic access as volatile in SelectionDAG. GlobalISEL keeps the two separate, but currently doesn't know how to lower an atomic G_LOAD at all. See https://reviews.llvm.org/D57601 for context.

The definition used for unordered was only checking volatility, not atomicity. As noted above, all atomic MMOs are currently also volatile, so this is a latent bug only. Copy the definition used in IR, after auditing the two (2) uses of the function to be sure the desired semantics are the same.

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

llvm-svn: 352898

llvm-svn: 352897

Summary:
The following patch introduces a new function `printSectionMapping` which is responsible for dumping just the section-to-segment mapping.
This patch also introduces a n option `-section-mapping` that outputs that mapping without the program headers.

Previously, this functionality was controlled by `printProgramHeaders`, and the output from `-program-headers` has not been changed.  I am happy to change the option name, I copied  the name that was displayed when outputting the mapping table.

Reviewers: khemant, jhenderson, grimar, rupprecht

Reviewed By: jhenderson, grimar, rupprecht

Subscribers: rupprecht, jhenderson, llvm-commits

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

llvm-svn: 352896

llvm-svn: 352895

llvm-svn: 352894

check-llvm already listed llvm-lit as script which counts as a dep, so running
check-llvm worked fine, but `ninja -C out/gn llvm/test` didn't build llvm-lit
before if it wasn't already there.

llvm-svn: 352893

Add checks for Win64 to existing cases.

llvm-svn: 352892

Summary:
The previous implementation reported `.comment` sections as '?'
GNU uses 'n' which means  "The symbol is a debugging symbol."  `.note`  sections are represented as 'n' too.

The test related to this change was updated to CHECK-NEXT to ensure
order and that we did not miss any symbols in the dump.

Reviewers: jhenderson

Reviewed By: jhenderson

Subscribers: rupprecht, llvm-commits

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

llvm-svn: 352891

Summary:
There is a bug for this: https://bugs.llvm.org/show_bug.cgi?id=34636
But it would be also helpful to leave a note in the docs to prevent users from
running into issues, e.g. https://crbug.com/926588.

Reviewers: morehouse

Reviewed By: morehouse

Subscribers: cfe-commits, llvm-commits, kcc

Tags: #clang

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

llvm-svn: 352890

[DWARF v5] Fix DWARF emitter and consumer to produce/expect a uleb for a location description's length.

Reviewer: davide, JDevliegere

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

llvm-svn: 352889

Summary:
Replace some reportError() calls with error propagation that was missed from rL352625.

Note this also adds an error check during Archive iteration that was being hidden by a different error check before:

```
  for (const Archive::Child &Child : Ar.children(Err)) {
    Expected<std::unique_ptr<Binary>> ChildOrErr = Child.getAsBinary();
    if (!ChildOrErr)
      // This aborts, so Err is never checked
      reportError(Ar.getFileName(), ChildOrErr.takeError());
```

Err is being checked after the loop, so during happy runs, everything is fine. But when reportError is changed to return the error instead of aborting, the fact that Err is never checked is now noticed in tests that trigger an error during the loop.

Reviewers: jhenderson, dblaikie, alexshap

Reviewed By: dblaikie

Subscribers: llvm-commits, lhames, jakehehrlich

Tags: #llvm

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

llvm-svn: 352888

llvm-svn: 352887

llvm-svn: 352886

Summary:
Incorrect code was generated when lowering insertelement operations
for vectors with 8 or 16 bit elements.  The value being inserted was
not adjusted for the position of the element within the 32 bit word
and so only the low element within each 32 bit word could receive
the intended value.

Fixed by simply replicating the value to each element of a
congruent vector before the mask and or operation used to
update the intended element.

A number of affected LIT tests have been updated appropriately.

before the mask & or into the intended

Reviewers: arsenm, nhaehnle

Reviewed By: arsenm

Subscribers: llvm-commits, arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye

Tags: #llvm

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

llvm-svn: 352885

The version of FoldConstantArithmetic() that takes arbitrary nodes
was confusingly naming those nodes as constants when they might
not be; also "Cst" reads like "Cast".

llvm-svn: 352884

As suggested on PR40318, this patch uses PSLLDQ/PSRLDQ to lower shuffles to zero out the ends of a vector, leaving a sequential inner section.

For pre-SSSE3 we do this for shuffles with zeros at either end (requiring up to 3 shifts), but once PSHUFB is available I've limited this to shuffles with a single zeroable end (2 shifts).

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

llvm-svn: 352883

Summary:
I'm working on a clang-tidy check, much like existing [[ http://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]],
to detect when an exception might escape out of an OpenMP construct it isn't supposed to escape from.
For that i will be using the `nothrow` bit of `CapturedDecl`s.

While that bit is already correctly set for some constructs, e.g. `#pragma omp parallel`: https://godbolt.org/z/2La7pv
it isn't set for the `#pragma omp sections`, or `#pragma omp section`: https://godbolt.org/z/qZ-EbP

If i'm reading [[ https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf | `OpenMP Application Programming Interface Version 5.0 November 2018` ]] correctly,
they should be, as per `2.8.1 sections Construct`, starting with page 86:
* The sections construct is a non-iterative worksharing construct that contains a set of **structured blocks**
  that are to be distributed among and executed by the threads in a team. Each **structured block** is executed
  once by one of the threads in the team in the context of its implicit task.
* The syntax of the sections construct is as follows:
  #pragma omp sections [clause[ [,] clause] ... ] new-line
    {
      [#pragma omp section new-line]
        **structured-block**
   ...
* Description
  Each **structured block** in the sections construct is preceded by a section directive except
  possibly **the first block**, for which a preceding section directive is optional.

* Restrictions
  • The code enclosed in a sections construct must be a **structured block**.
  * A throw executed inside a sections region must cause execution to resume within the same
    section of the sections region, and the same thread that threw the exception must catch it.

Reviewers: ABataev, #openmp

Reviewed By: ABataev

Subscribers: guansong, openmp-commits, cfe-commits

Tags: #clang, #openmp

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

llvm-svn: 352882

Summary:
Apparently `LLVMTestingSupport` must be built before `llvm-config` can be asked for it. Symptom with `LLVM_INCLUDE_TESTS=ON` is:
```
$ ./path/to/llvm-build/bin/llvm-config --ldflags --libs testingsupport
-L/path/to/llvm-build/lib -Wl,-search_paths_first -Wl,-headerpad_max_install_names
llvm-config: error: component libraries and shared library

llvm-config: error: missing: /path/to/llvm-build/lib/libLLVMTestingSupport.a
```

With `LLVMTestingSupport` as dependency of `compiler-rt-configure` we get the expected behavior:
```
$ ./path/to/llvm-build/bin/llvm-config --ldflags --libs testingsupport
-L/path/to/llvm-build/lib -Wl,-search_paths_first -Wl,-headerpad_max_install_names
-lLLVMTestingSupport -lLLVMSupport -lLLVMDemangle
```

Reviewers: ab, beanz

Subscribers: dberris, mgorny, erik.pilkington, llvm-commits, cfe-commits

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

llvm-svn: 352881