git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283616 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283615 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283611 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283605 91177308-0d34-0410-b5e6-96231b3b80d8

Revert the -print-libgcc-file-name change as the new test fails
on Darwin. It needs to be updated to run the libgcc part only on systems
supporting that rtlib.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283586 91177308-0d34-0410-b5e6-96231b3b80d8

Make the -print-libgcc-file-name option print an appropriate compiler
runtime library, that is libgcc.a if gcc runtime is used
and an appropriate compiler-rt library if that runtime is used.

The main use for this is to allow linking executables built with
-nodefaultlibs (e.g. to avoid linking to the standard C++ library) to
the compiler runtime library, e.g. using:

  clang++ ... -nodefaultlibs $(clang++ ... -print-libgcc-file-name)

in which case currently a program built like this linked to the gcc
runtime unconditionally. The patch fixes it to use compiler-rt libraries
instead when compiler-rt is the active runtime.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283572 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283527 91177308-0d34-0410-b5e6-96231b3b80d8

Provide toolchain and tool support for Fuchsia operating system.
Fuchsia uses compiler-rt as the runtime library and libc++, libc++abi
and libunwind as the C++ standard library. lld is used as a default
linker.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283420 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283417 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283258 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283257 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts 283193 -- broke the build.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283199 91177308-0d34-0410-b5e6-96231b3b80d8

Added the code which explicitly emits an error in Clang in case
`-fxray-instrument` is passed, but XRay is not supported for the
selected target.

Author: rSerge

Reviewers: dberris, rsmith, aaron.ballman, rnk

Subscribers: cfe-commits, iid_iunknown

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283193 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.

Patch mostly by EricWF.

Reviewers: rnk, cfe-commits, rsmith, EricWF

Subscribers: mehdi_amini

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283064 91177308-0d34-0410-b5e6-96231b3b80d8

Enable soft-float support on PPC64, as the backend now supports it. Also, the
backend now uses -hard-float instead of +soft-float, so set the target features
accordingly.

Fixes PR26970.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283061 91177308-0d34-0410-b5e6-96231b3b80d8

assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282974 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch proposes a new class to generate and record action dependences related with offloading. The builder provides three main functionalities:
- Add device dependences to host actions.
- Add host dependence to device actions.
- Register device top-level actions.

The constructor of the builder detect the programming models that should be supported, and generates a specialized builder for each. If a new programming model is to be added in the future, only a new specialized builder has to be implemented. 

When the specialized builder is generated, it produces programming-model-specific diagnostics.

A CUDA specialized builder is proposed in the patch that mostly consists of the partition of the current  `buildCudaAction` by the three different functionalities.

Reviewers: tra, echristo, ABataev, jlebar, hfinkel

Subscribers: Hahnfeld, whchung, guansong, jlebar, mehdi_amini, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282865 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282757 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282610 91177308-0d34-0410-b5e6-96231b3b80d8

This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282426 91177308-0d34-0410-b5e6-96231b3b80d8

Avoid failing in the backend when the rewrite map does not exist.  Rather check
that the map exists in the frontend before handing it off to the backend.  Add
the missing rewrite maps that the tests were referencing.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282379 91177308-0d34-0410-b5e6-96231b3b80d8

This should fix the android build in this bot:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/11143

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282308 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Currently, a linker option must be used to control the backend
parallelism of ThinLTO. The linker option varies depending on the
linker (e.g. gold vs ld64). Add a new clang option -flto-jobs=N
to control this.

I've added in the wiring to pass this to the gold plugin. I also
added in the logic to pass this down in the form I understand that
ld64 uses on MacOS, for the darwin target.

Reviewers: mehdi_amini, dexonsmith

Subscribers: mehdi_amini, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282291 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
The ASAN unittests are failing (check-asan-dynamic) due to an incorrect symbol name:
```
LINK : error LNK2001: unresolved external symbol ___asan_seh_interceptor
```

On win64, the linker is not adding an extra underscore. This was correctly fixed in the same file for other uses.

After that patch, most of the unittests are passing, but some related to SEH needs to be fixed.
```
Failing Tests (4):
    AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memchr.cc
    AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
    AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_seh.cc
    AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/seh.cc

  Expected Passes    : 339
  Passes With Retry  : 3
  Expected Failures  : 16
  Unsupported Tests  : 152
  Unexpected Failures: 4
```

Reviewers: rnk, kcc, majnemer

Subscribers: majnemer, chrisha, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282251 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282007 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Sanitizers aren't supported on NVPTX -- don't try to run them.

This lets you e.g. pass -fsanitize=address and get asan on your host
code.

Reviewers: kcc

Subscribers: cfe-commits, tra, jhen

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281680 91177308-0d34-0410-b5e6-96231b3b80d8

Unfortunately we can't enable it for all N64 because it is not yet possible to
distinguish N32 from N64 from the triple on other environments.

N64 has been confirmed to produce identical (within reason) objects to GAS
during stage 2 of compiler recursion on N64-abi Fedora. Unfortunately,
Fedora's triples do not distinguish N32 from N64 so I can't enable it by
default there. I'm currently repeating this testing for Debian mips64el but
it's very unlikely to produce a different result.

Patch by: Daniel Sanders

Reviewers: sdardis

Differential Review: https://reviews.llvm.org/D22679


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281610 91177308-0d34-0410-b5e6-96231b3b80d8

[sanitizer-coverage] add yet another flavour of coverage instrumentation: trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this one. Clang part

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281432 91177308-0d34-0410-b5e6-96231b3b80d8

Original commit message:

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region.  This uses PGO and allows
filtering of the optimization remarks by relevance.  The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks.  Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281293 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r281276.

Many bots are failing.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281279 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region.  This uses PGO and allows
filtering of the optimization remarks by relevance.  The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks.  Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281276 91177308-0d34-0410-b5e6-96231b3b80d8

This is a spiritual re-commit of r201375 with only a brief delay
for upgrading the green dragon builders.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281094 91177308-0d34-0410-b5e6-96231b3b80d8

Doesn't work, but needs to be enabled in order to get there.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281071 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280998 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewed by bruening
Differential: D23800


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280806 91177308-0d34-0410-b5e6-96231b3b80d8

-fprofile-dir=path allows the user to specify where .gcda files should be
emitted when the program is run. In particular, this is the first flag that
causes the .gcno and .o files to have different paths, LLVM is extended to
support this. -fprofile-dir= does not change the file name in the .gcno (and
thus where lcov looks for the source) but it does change the name in the .gcda
(and thus where the runtime library writes the .gcda file). It's different from
a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip
paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX.

To implement this we split -coverage-file into -coverage-data-file and
-coverage-notes-file to specify the two different names. The !llvm.gcov
metadata node grows from a 2-element form {string coverage-file, node dbg.cu}
to 3-elements, {string coverage-notes-file, string coverage-data-file, node
dbg.cu}. In the 3-element form, the file name is already "mangled" with
.gcno/.gcda suffixes, while the 2-element form left that to the middle end
pass.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280306 91177308-0d34-0410-b5e6-96231b3b80d8

I tested the cases involving split-dwarf + gmlt +
no-split-dwarf-inlining, but didn't verify the simpler case without
gmlt.

The logic is, admittedly, a little hairy, but seems about as simple as I
could wrangle it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280290 91177308-0d34-0410-b5e6-96231b3b80d8

This breaks chromium and its unclear if this is actually a modern convention.

This reverts SVN r280169.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280281 91177308-0d34-0410-b5e6-96231b3b80d8

On Windows, static libraries are named lib<name>.lib while import libraries are
named <name>.lib.  Use the appropriate naming on itanium and msvc environments.
This is setup properly so that if a dynamic builtins is used on Windows, it
would do the right thing, although this is not currently wired through the
driver (i.e. there is no equivalent to -{shared,static}-gcc).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280169 91177308-0d34-0410-b5e6-96231b3b80d8

r280133. Original commit message:

C++ Modules TS: driver support for building modules.

This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.

The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.

As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.

This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280134 91177308-0d34-0410-b5e6-96231b3b80d8