Run clang -cc1 -E instead of -S, in an attempt to make this test work
cross-platform.

llvm-svn: 287292

StartFunction enters a release cleanup for ns_consumed arguments in
ARC, so we need to balance that somehow.  We could teach StartFunction
that it's emitting a delegating function, so that the cleanup is
unnecessary, but that would be invasive and somewhat fraught.  We could
balance the consumed argument with an extra retain, but clearing the
original variable should be easier to optimize and avoid some extra work
at -O0.  And there shouldn't be any difference as long as nothing else
uses the argument, which should always be true for the places we emit
delegate arguments.

Fixes PR 27887.

llvm-svn: 287291

llvm-svn: 287290

llvm-svn: 287289

Reviewers: tra

Subscribers: cfe-commits

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

llvm-svn: 287288

Reviewers: tra

Subscribers: cfe-commits

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

llvm-svn: 287287

Summary:
This used to work because system headers are found in a (somewhat)
predictable set of locations on Linux.  But this is not the case on
MacOS; without this change, we don't look in the right places for our
headers when doing device-side compilation on Mac.

Reviewers: tra

Subscribers: cfe-commits

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

llvm-svn: 287286

Summary:
Compiling CUDA device code requires us to know the host toolchain,
because CUDA device-side compiles pull in e.g. host headers.

When we only supported Linux compilation, this worked because
CudaToolChain, which is responsible for device-side CUDA compilation,
inherited from the Linux toolchain.  But in order to support MacOS,
CudaToolChain needs to take a HostToolChain pointer.

Because a CUDA toolchain now requires a host TC, we no longer will
create a CUDA toolchain from Driver::getToolChain -- you have to go
through CreateOffloadingDeviceToolChains.  I am *pretty* sure this is
correct, and that previously any attempt to create a CUDA toolchain
through getToolChain() would eventually have resulted in us throwing
"error: unsupported use of NVPTX for host compilation".

In any case hacking getToolChain to create a CUDA+host toolchain would
be wrong, because a Driver can be reused for multiple compilations,
potentially with different host TCs, and getToolChain will cache the
result, causing us to potentially use a stale host TC.

So that's the main change in this patch.

In addition, we have to pull CudaInstallationDetector out of Generic_GCC
and into a top-level class.  It's now used by the Generic_GCC and MachO
toolchains.

Reviewers: tra

Subscribers: rryan, hfinkel, sfantao

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

llvm-svn: 287285

llvm-svn: 287284

These are part of the EHABI specification and are exported to be available to
users.  Mark them as `_LIBUNWIND_EXPORT` like the rest of the unwind interfaces.

llvm-svn: 287283

This resubmits r287279 with a fix for the original issue, which
was a trivial typo.

llvm-svn: 287282

This reverts commit r287279, which breaks some register
tests on Linux.

llvm-svn: 287281

Since the output has a section table too, it is meaningful to compute
the sh_link. In a more practical note, the binutils' strip crashes if
sh_link is not set for SHT_ARM_EXIDX.

llvm-svn: 287280

In the process, found some functions that were duplicates of
existing StringRef member functions.  So deleted those functions
and used the StringRef functions instead.

llvm-svn: 287279

I made several changes for consistency with the rest of x86 instrinsics header files. Some of these changes help to render doxygen comments better.

1. avxintrin.h –  Moved the opening bracket on a separate line for several 
                  intrinsics (for consistency with the rest of the intrinsics).

2. emmintrin.h -  Moved the doxygen comment next to the body of the function;
               -  Added braces after extern "C"  even though there is only 
                  one declaration each time

3. xmmintrin.h -  Moved the doxygen comment next to the body of the function;
               -  Added intrinsic prototypes for a couple of macro definitions
                  into the doxygen comment;
               -  Added braces after extern "C"  even though there is only one
                  declaration each time

4. ammintrin.h –  Removed extra line between the doxygen comment and the body
                  of the functions (for consistency with the rest of the files).

Desk reviewed by Paul Robinson.

llvm-svn: 287278

llvm-svn: 287277

llvm-svn: 287276

Re-introduce r285411.

Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.

This change aims to add this option, pass it through to the preprocessor via
the options class, and when inclusions occur we output some information (+ test
cases).

Patch by Steve O'Brien!

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

llvm-svn: 287275

Summary:
Fix step-over when SymbolContext.function is missing and symbol is present.

With targets from our build configuration,
ThreadPlanStepOverRange::IsEquivalentContext fails to fire for relevant frames,
leading to ShouldStop() returning true prematurely.

The frame's SymbolContext, and m_addr_context have:
  - comp_unit set and matching
  - function = nullptr
  - symbol set and matching (but this is never checked)
My naive guess is that the context should be equivalent in this case :-)

Reviewers: jingham

Subscribers: lldb-commits

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

llvm-svn: 287274

llvm-svn: 287273

Do not assume a load to be hoistable/invariant if the pointer is used by
another instruction in the SCoP that might write to memory and that is
always executed.

llvm-svn: 287272

The declaration as an "error block" is currently aggressive and not very
smart. This patch allows to disable error blocks completely. This might
be useful to prevent SCoP expansion to a point where the assumed context
becomes infeasible, thus the SCoP has to be discarded.

llvm-svn: 287271

Since we do not necessarily treat memory intrinsics as non-affine
anymore, we have to check for them explicitly before we try to hoist an
access.

llvm-svn: 287270

Filter trivial assumptions, thus assume { : } or restrict { : 0 = 1 },
as they clutter the user output as well as the statistics.

llvm-svn: 287269

Subscribers: kubabrecka

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

llvm-svn: 287268

llvm-svn: 287267

This one is fairly trivial and only really involves changing
function signatures and a few simple call-sites.

llvm-svn: 287266

The new command line flag "polly-codegen-emit-rtc-print" can be used to
place a "printf" in the generated code that will print the RTC value and
the overflow state.

llvm-svn: 287265

Also add new comments with MIPS GOT description.

llvm-svn: 287264

llvm-svn: 287263

In addition to the preprocessed sources file and reproducer script, also
point to the .crash diagnostic files on Darwin. Example:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cpp
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cache
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.sh
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.crash

When no match is found for the .crash, point the user to a directory
where those can be found. Example:

clang-4.0: note: diagnostic msg: Crash backtrace is located in
clang-4.0: note: diagnostic msg: /Users/bruno/Library/Logs/DiagnosticReports/clang-4.0_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang-4.0: note: diagnostic msg: (choose the .crash file that corresponds to your crash)

rdar://problem/27286266

llvm-svn: 287262

llvm-svn: 287261

I hit an internal linker script that was defining _DYNAMIC instead of
letting the linker do it. It turns out that both bfd and gold allow
that.

This is pretty easy to implement, just make the linker defined symbol
weak. This should have no impact in the case where there is no user
defined symbol: The visibility is hidden, which causes the output to
still be local.

llvm-svn: 287260

All tests pass on Linux and Windows.

llvm-svn: 287259

llvm-svn: 287258

Linker script doesn't create a section if it has no content. So the following
script doesn't create .norelocs section if it doesn't have any .rel* sections.

  .norelocs : { *(.rel*) }

Later, if you assert that the size of .norelocs is 0, LLD printed out
an error message, because it didn't allow calling SIZEOF() on nonexistent
sections.

This patch allows SIZEOF() on nonexistent sections, so that you can do
something like this.

  ASSERT(SIZEOF(.norelocs), "shouldn't contain .rel sections!")

Note that this behavior is compatible with GNU.

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

llvm-svn: 287257

lld on Darwin does not currently support LTO.

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

llvm-svn: 287256

llvm-svn: 287255

llvm-svn: 287254

llvm-svn: 287253