Autoconf and some other systems tend to add essential compilation
options to CC (e.g. -std=gnu99). When running such an auto-generated
makefile, scan-build does not need to change CC and CXX as they are
already set to use ccc-analyzer by a configure script.

Implement a new option --keep-cc as was proposed in this discussion:
http://lists.llvm.org/pipermail/cfe-dev/2013-September/031832.html

Patch by Paul Fertser!

llvm-svn: 323665

clang's -x option doesn't accept c-cpp-output as a language (even though
463eb6ab was merged, the driver still doesn't handle that).

This bug prevents testing C language projects when ccache is used.

Fixes #25851.

Investigation and patch by Dave Rigby.

llvm-svn: 323664

llvm-svn: 323663

Summary:
If the same value is going to be vectorized several times in the same
tree entry, this entry is considered to be a gather entry and cost of
this gather is counter as cost of InsertElementInstrs for each gathered
value. But we can consider these elements as ShuffleInstr with
SK_PermuteSingle shuffle kind.

Reviewers: spatel, RKSimon, mkuper, hfinkel

Subscribers: llvm-commits

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

llvm-svn: 323662

llvm-svn: 323661

Summary:
o Replace the existing clangd::URI with a wrapper of FileURI which also
carries a resolved file path.
o s/FileURI/URI/
o Get rid of the URI hack in vscode extension.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits

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

llvm-svn: 323660

MSVC complains that the constexpr "expression did not evaluate to a
constant". Trying to make it happy by adding a `const` specifier as
suggested in https://stackoverflow.com/questions/37574343.

llvm-svn: 323659

Reviewers: hokein, sammccall

Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits

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

llvm-svn: 323658

There was a failure on a bot:
http://lab.llvm.org:8011/builders/clang-cmake-mipsel/builds/1283

strerror test is indeed flaky. We protect all races by a barrier in other tests
to eliminate flakiness. Do the same here.

No idea why tls_race2.cc failed. Add output at the end of the test
as we do in other tests. Sometimes test process crashes somewhere
in the middle (e.g. during race reporting) and it looks like empty output.
Output at the end of test allows to understand if the process has crashed,
or it has finished but produced no race reports.

Reviewed in https://reviews.llvm.org/D42633

llvm-svn: 323657

Fixes the missing reference in AppleAccelTableData by making the method
pure virtual as intended.

llvm-svn: 323656

This patch adds support for generating accelerator tables in dsymutil.
This feature was already present in our internal repository but not yet
upstreamed because it requires changes to the Apple accelerator table
implementation.

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

llvm-svn: 323655

This patch renames DwarfAccelTable.{h,cpp} to AccelTable.{h,cpp} and
moves the header to the include dir so it is accessible by the
dsymutil implementation.

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

llvm-svn: 323654

This patch refactors the way data is stored in the accelerator table and
makes them truly generic. There have been several attempts to do this in
the past:

 - D8215 & D8216: Using a union and partial hardcoding.
 - D11805: Using inheritance.
 - D42246: Using a callback.

In the end I didn't like either of them, because for some reason or
another parts of it felt hacky or decreased runtime performance. I
didn't want to completely rewrite them as I was hoping that we could
reuse parts for the successor in the DWARF standard. However, it seems
less and less likely that there will be a lot of opportunities for
sharing code and/or an interface.

Originally I choose to template the whole class, because it introduces
no performance overhead compared to the original implementation.

We ended up settling on a hybrid between a templated method and a
virtual call to emit the data. The motivation is that we don't want to
increase code size for a feature that should soon be superseded by the
DWARFv5 accelerator tables. While the code will continue to be used for
compatibility, it won't be on the hot path. Furthermore this does not
regress performance compared to Apple's internal implementation that
already uses virtual calls for this.

A quick summary for why these changes are necessary: dsymutil likes to
reuse the current implementation of the Apple accelerator tables.
However, LLDB expects a slightly different interface than what is
currently emitted. Additionally, in dsymutil we only have offsets and no
actual DIEs.

Although the patch suggests a lot of code has changed, this change is
pretty straightforward:

 - We created an abstract class `AppleAccelTableData` to serve as an
   interface for the different data classes.
 - We created two implementations of this class, one for type tables and
   one for everything else. There will be a third one for dsymutil that
   takes just the offset.
 - We use the supplied class to deduct the atoms for the header which
   makes the structure of the table fully self contained, although not
   enforced by the interface as was the case for the fully templated
   approach.
 - We renamed the prefix from DWARF- to Apple- to make space for the
   future implementation of .debug_names.

This change is NFC and relies on the existing tests.

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

llvm-svn: 323653

Code building the AST expected that construction of CompilerInstance
always succeeds. This is not the case.

llvm-svn: 323652

See bugs 36092, 36093:
    https://bugs.llvm.org/show_bug.cgi?id=36092
    https://bugs.llvm.org/show_bug.cgi?id=36093

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

Reviewers: vpykhtin, artem.tamazov, arsenm
llvm-svn: 323651

llvm-svn: 323650

This patch implements the device runtime library whose interface is used in the code generation for OpenMP offloading devices.
Currently there is a single device RTL written in CUDA meant to CUDA enabled GPUs.
The interface is a variation of the kmpc interface that includes some extra calls to do thread and storage management that only make sense for a GPU target.

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

llvm-svn: 323649

The test was failing because of an incorrect sizeof check in the name
index parsing code. This code was meant to check that we have enough
input to parse the fixed-size part of the dwarf header, which it did by
comparing the input to sizeof(Header). Originally struct Header only
contained the fixed-size part, but during review, we've moved additional
members into it, which rendered the sizeof check invalid.

I resolve this by moving the fixed-size part to a separate struct and
updating the sizeof-expression to use that.

llvm-svn: 323648

[Lexer] Support adding working directory to relative search dir for #include shortening in HeaderSearch.

Reviewers: bkramer

Subscribers: mgorny, hintonda, cfe-commits

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

llvm-svn: 323647

Summary:
All variants of isLogicalImm[Not](32|64) can be combined into a single templated function, same for printLogicalImm(32|64).
By making it use a template instead, further SVE patches can use it for other data types as well (e.g. 8, 16 bits).

Reviewers: fhahn, rengolin, aadg, echristo, kristof.beyls, samparker

Reviewed By: samparker

Subscribers: aemerson, javed.absar, llvm-commits

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

llvm-svn: 323646

`num_args` is unsigned integer, declared as below:

```
uint32_t num_args = arg_enum->getChildCount();
```

Comparison with the signed `arg_idx` produces a warning when compiled with
-Wsign-compare flag, this patch addresses this simple issue without affecting
any functionality.

Reviewers: davide, asmith
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42620

llvm-svn: 323645

Summary:
When emitting the location for a global variable with fragmented debug
expressions, make sure that the offset pieces, which represent
optimized-out parts of the variable, are emitted before their succeeding
fragments' expressions. Previously, if the succeeding fragment's
location was a symbol, the offset piece was emitted after, rather than
before, that symbol's expression. This effectively meant that the symbols
were associated with the wrong parts of the variable.

This fixes PR36085.

Patch by: David Stenberg

Reviewers: aprantl, probinson, dblaikie

Reviewed By: aprantl

Subscribers: JDevlieghere, llvm-commits

Tags: #debug-info

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

llvm-svn: 323644

Summary: This was broken long ago in D12208, which failed to account for
the fact that 64-bit SPARC uses a stack bias of 2047, and it is the
*unbiased* value which should be aligned, not the biased one. This was
seen to be an issue with Rust.

Patch by: jrtc27 (James Clarke)

Reviewers: jyknight, venkatra

Reviewed By: jyknight

Subscribers: jacob_hansen, JDevlieghere, fhahn, fedor.sergeev, llvm-commits

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

llvm-svn: 323643

The call to ScopedPrinter::printNumber with size_t argument was
ambiguous (I think) on 32-bit builds. Explicitly cast to a 64-bit int to
avoid this.

llvm-svn: 323642

Summary:
This modifies the dwarfdump output to align it with the new .debug_names
dump. It also renames two header fields to match similar fields in the
dwarf5 header.

A couple of tests needed to be updated to match new output. The changes
were fairly straight-forward, although not really automatable.

Reviewers: JDevlieghere, aprantl

Subscribers: llvm-commits

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

llvm-svn: 323641

Create and use FP16Pat FullFP16Pat helper patterns to make the difference
explicit.

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

llvm-svn: 323640

llvm-svn: 323639

Summary:
This commit renames DWARFAcceleratorTable to AppleAcceleratorTable to free up
the first name as an interface for the different accelerator tables.
Then I add a DWARFDebugNames class for the dwarf5 table.

Presently, the only common functionality of the two classes is the dump()
method, because this is the only method that was necessary to implement
dwarfdump -debug-names; and because the rest of the
AppleAcceleratorTable interface does not directly transfer to the dwarf5
tables (the main reason for that is that the present interface assumes
the tables are homogeneous, but the dwarf5 tables can have different
keys associated with each entry).

I expect to make the common interface richer as I add more functionality
to the new class (and invent a way to represent it in generic way).

In terms of sharing the implementation, I found the format of the two
tables sufficiently different to frustrate any attempts to have common
parsing or dumping code, so presently the implementations share just low
level code for formatting dwarf constants.

Reviewers: vleschuk, JDevlieghere, clayborg, aprantl, probinson, echristo, dblaikie

Subscribers: llvm-commits

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

llvm-svn: 323638

Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two issues with
this:
- it's in the wrong layer
- the call can be very expensive (it can end up computing the crc of the
  whole file).

Since the process is running on the host, ideally we would be able to
just query the data straight from the OS like darwin does, but there
doesn't seem to be a reasonable way to do that. So, this fixes the
layering issue by using the llvm object library to inspect the file.
Since we know the process is already running on the host, we just need
to peek at a few bytes of the elf header to determine whether it's 32-
or 64-bit (which should make this faster as well).

Pretty much the same logic was implemented in
NativeProcessProtocol::ResolveProcessArchitecture, so I delete this
logic and replace calls with GetProcessInfo.

Reviewers: eugene, krytarowski

Subscribers: mgorny, hintonda, lldb-commits

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

llvm-svn: 323637

Summary:
Adds new utilities that make it easier to write test cases for lldb acting as a client over a gdb-remote connection.

- A GDBRemoteTestBase class that starts a mock GDB server and provides an easy way to check client packets
- A MockGDBServer that, via MockGDBServerResponder, can be made to issue server responses that test client behavior.
- Utility functions for handling common data encoding/decoding
- Utility functions for creating dummy targets from YAML files

----

Split from the review at https://reviews.llvm.org/D42145, which was a new feature that necessitated the new testing capabilities.

Reviewers: clayborg, labath

Reviewed By: clayborg, labath

Subscribers: hintonda, davide, jingham, krytarowski, mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D42195
Patch by Owen Shaw <llvm@owenpshaw.net>

llvm-svn: 323636

Summary: The issues was found during D40524.

Reviewers: andrew.w.kaylor, craig.topper, MatzeB

Reviewed By: andrew.w.kaylor

Subscribers: aivchenk, llvm-commits

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

llvm-svn: 323635

The Large System Extension added an atomic compare-and-swap instruction
that operates on a pair of 64-bit registers, which we can use to
implement a 128-bit cmpxchg.

Because i128 is not a legal type for AArch64 we have to do all of the
instruction selection in C++, and the instruction requires even/odd
register pairs, so we have to wrap it in REG_SEQUENCE and EXTRACT_SUBREG
nodes. This is very similar to what we do for 64-bit cmpxchg in the ARM
backend.

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

llvm-svn: 323634

Implementation marks non-prevailing symbols as not live in the summary.
Then them are dropped in backends.

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

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

llvm-svn: 323633

Summary:
There's a check in the code to only check getSetCCResultType after LegalOperations or if the type is MVT::i1. But the i1 check is only allowing scalar types through. I think it should check that the scalar type is MVT::i1 so that it will work for vectors.

The changed test already does this combine with AVX512VL where getSetCCResultType returns vXi1. But with avx512f and no VLX getSetCCResultType returns a type matching the width of the input type.

Reviewers: spatel, RKSimon

Reviewed By: spatel

Subscribers: llvm-commits

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

llvm-svn: 323631

This pretty much reverts r322006, except that we keep the test,
because we work around the issue exposed in a different way (a
recursion limit in value tracking). There's still probably some
sequence that exposes this problem, and the proper way to fix that
for somebody who has time is outlined in the code review.

llvm-svn: 323630

Looks like it broke a bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/builds/7195
Reverting until I have a chance to investigate.

llvm-svn: 323629

"to to" -> "to"

llvm-svn: 323628

"to to" -> "to"

llvm-svn: 323627

`set_target_compile_flags()` ultimately sets COMPILE_FLAGS which is
added to CMAKE_CXX_FLAGS in the compile rule, so passing
CMAKE_CXX_FLAGS causes them to be duplicated.

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

llvm-svn: 323626

This should fix PR36017.

The root problem is that we were creating a PT_LOAD just for the
header. That was technically valid, but inconvenient: we should not be
making the ELF discontinuous.

The solution is to allow a section with LMAExpr to be added to a
PT_LOAD if that PT_LOAD doesn't already have a LMAExpr.

llvm-svn: 323625