I made the wrong assumption that execution would continue after an error Diag
which led to unneeded complex code.
This patch aligns with the better implementation of ToolChain::GetRuntimeLibType.
Differential Revision: https://reviews.llvm.org/D25669
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289422 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The MSVC toolchain and Clang driver combination currently uses a fairly complex
sequence of steps to determine the MS compatibility version to pass to cc1.
There is some oddness in this sequence currently, with some code which inspects
flags in the toolchain, and some code which inspects the triple and local
environment in the driver code.
This change is an attempt to consolidate most of this logic so that
Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the
split, so any suggestions are welcome.
There are a few things you might want to watch for for specifically:
- On all platforms, if MSVC compatibility flags are provided (and valid), use
those.
- The fallback sequence should be the same as before, but is now consolidated
into MSVCToolChain::getMSVCVersion:
- Otherwise, try to use the Triple.
- Otherwise, on Windows, check the executable.
- Otherwise, on Windows or with --fms-extensions, default to 18.
- Otherwise, we can't determine the version.
- MSVCToolChain::ComputeEffectiveTriple no longer calls the base
ToolChain::ComputeEffectiveClangTriple. The only thing it would change for
Windows the architecture, which we don't care about for the compatibility
version.
- I'm not sure whether this is philosophically correct (but it should
be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not).
- Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look
like the effective triple was always being used previously anyhow.
Reviewers: hans, compnerd, llvm-commits, rnk
Subscribers: amccarth
Differential Revision: https://reviews.llvm.org/D27477
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288998 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch adds the support to create a job for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21856
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285325 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Each time that offloading support is requested by the user and the input file is not a source file, an action `OffloadUnbundlingAction` is created to signal that the input file may contain bundles, so that the proper tool is then invoked to attempt to extract the components of the bundle. This patch adds the logic to create that action in offload action builder.
The job creation for the new action will be proposed in a separate patch.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21853
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285324 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In order to save the user from dealing with multiple output files (for host and device) while using separate compilation, a new action `OffloadBundlingAction` is used when the last phase is not linking. This action will then result in a job that uses the proposed bundling tool to create a single preprocessed/IR/ASM/Object file from multiple ones.
The job creation for the new action will be proposed in a separate patch.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21852
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285323 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
Compute an effective triple once per job. Cache the triple in the
prevailing ToolChain for the duration of the job.
Clients which need effective triples now look them up in the ToolChain.
This eliminates wasteful re-computation of effective triples (e.g in
getARMFloatABI()).
While we're at it, delete MachO::ComputeEffectiveClangTriple. It was a
no-op override.
Differential Revision: https://reviews.llvm.org/D22596
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276937 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r275895 in order to address some post-commit review
feedback from Eric Christopher (see: the list thread for r275895).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276936 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru
which we can specify a default value for -rtlib (libgcc or
compiler-rt) at build time, just like how we set the default C++
stdlib thru CLANG_DEFAULT_CXX_STDLIB.
With these two options, we can configure clang to build binaries on
Linux that have no runtime dependence on any gcc libs (libstdc++ or
libgcc_s).
Patch by Lei Zhang!
Differential Revision: https://reviews.llvm.org/D22663
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276848 91177308-0d34-0410-b5e6-96231b3b80d8
Compute an effective target triple exactly once in ConstructJob(), and
then simply pass around references to it. This eliminates wasteful
re-computation of effective triples (e.g in getARMFloatABI()).
Differential Revision: https://reviews.llvm.org/D22290
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275895 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs.
This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture.
This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures)
```
0: input, "cudatests.cu", cuda, (host-cuda)
1: preprocessor, {0}, cuda-cpp-output, (host-cuda)
2: compiler, {1}, ir, (host-cuda)
3: input, "cudatests.cu", cuda, (device-cuda, sm_35)
4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35)
5: compiler, {4}, ir, (device-cuda, sm_35)
6: backend, {5}, assembler, (device-cuda, sm_35)
7: assembler, {6}, object, (device-cuda, sm_35)
8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object
9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler
10: input, "cudatests.cu", cuda, (device-cuda, sm_37)
11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37)
12: compiler, {11}, ir, (device-cuda, sm_37)
13: backend, {12}, assembler, (device-cuda, sm_37)
14: assembler, {13}, object, (device-cuda, sm_37)
15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object
16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler
17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda)
18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir
19: backend, {18}, assembler
20: assembler, {19}, object
21: input, "cuda", object
22: input, "cudart", object
23: linker, {20, 21, 22}, image
```
The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine.
Reviewers: echristo, hfinkel, jlebar, ABataev, tra
Subscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D18171
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275645 91177308-0d34-0410-b5e6-96231b3b80d8
This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Recognize and use IAMCU GCC toolchain
* Set up include paths
* Forbid C++
Differential Revision: http://reviews.llvm.org/D19274
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272883 91177308-0d34-0410-b5e6-96231b3b80d8
This patch extends the -fuse-ld option to accept a full path to an executable
and use it verbatim to invoke the linker. There are generally two reasons
to desire this.
The first reason relates to the sad truth is that Clang is retargetable,
Binutils are not.
While any Clang from a binary distribution is sufficient to compile code
for a wide range of architectures and prefixed BFD linkers (e.g.
installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as cross-compiled
libc's (for non-bare-metal targets) are widely available, including on all
Debian derivatives, it is impossible to use them together because
the -fuse-ld= option allows to specify neither a linker prefix nor
a full path to one.
The second reason is linker development, both when porting existing linkers
to new architectures and when working on a new linker such as LLD.
Differential Revision: http://reviews.llvm.org/D17952
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262996 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to construct Linux toolchains without a valid linker. This
is needed for example to build a CUDA device toolchain after r253385.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253707 91177308-0d34-0410-b5e6-96231b3b80d8
In order to compile a CUDA file clang must be able to find
include files for both both host and device.
This patch passes AuxToolchain to AddPreprocessingOptions and
uses it to add include paths for the opposite side of compilation.
We also must be able to find CUDA include files. If the driver
found CUDA installation, it adds appropriate include path
to CUDA headers. This can be disabled with '-nocudainc'.
- Added include paths for the opposite side of compilation.
- Added include paths to detected CUDA installation.
- Added -nocudainc to prevent adding CUDA include path.
- Added test cases to verify new functionality.
Differential Revision: http://reviews.llvm.org/D13170
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253386 91177308-0d34-0410-b5e6-96231b3b80d8
Last time, this caused two Windows buildbots and a single ARM buildbot to fail.
I XFAIL'd the failing test on win32,win64 machines in order to see if the ARM
buildbot complains again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252901 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commits r251633. I'll investigate the test failure off trunk in
order to keep the buildbots clean.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251698 91177308-0d34-0410-b5e6-96231b3b80d8
The original commit in r249137 added the mips-mti-linux toolchain. However,
the newly added tests of that commit failed in few buildbots. This commit
re-applies the original changes but XFAILs the test file which caused
the buildbot failures. This will allow us to examine what's going wrong
without having to commit/revert large changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251633 91177308-0d34-0410-b5e6-96231b3b80d8
that has a thumb only CPU by default (cortex-m3), and when using the assembler,
the default thumb state of the CPU does not get passed via the triple to LLVM:
$ clang -target thumbv7m-none-eabi -c -v test.s
clang -cc1as ... -triple armv7m-none--eabi ... test.s
Differential Revision: http://reviews.llvm.org/D14121
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251507 91177308-0d34-0410-b5e6-96231b3b80d8
In this patch, the file static method addProfileRT is
moved to be a virtual member function of base ToolChain class.
This allows derived toolchain to override the default behavior
easily and make it consistent with Darwin toolchain (a TODO was
added for this refactoring - now removed). A new helper method
is also introduced to test if instrumentation profile option
is turned on or not.
Differential Revision: http://reviews.llvm.org/D13326
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250994 91177308-0d34-0410-b5e6-96231b3b80d8
There are still some loose ends here but it's sufficient so we can detect
GCC headers that are inside of a VFS.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249556 91177308-0d34-0410-b5e6-96231b3b80d8
There are two remaining buildbot failures that we'll have to
investigate before submitting this again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249298 91177308-0d34-0410-b5e6-96231b3b80d8
r249137 added support for the new mips-mti-linux toolchain. However,
the new tests of that commit, broke some buildbots because they didn't use
the correct regular expressions to capture the filename of Clang & LLD.
This commit re-applies the changes of r249137 and fixes the tests in
r249137 in order to match the filenames of the Clang and LLD executable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249294 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This new toolchain uses primarily LLVM-based tools, eg. compiler-rt, lld,
libcxx, etc. Because of this, it doesn't require neither an existing GCC
installation nor a GNU environment. Ideally, in a follow-up patch we
would like to add a new --{llvm|clang}-toolchain option (similar to
--gcc-toolchain) in order to allow the use of this toolchain with
independent Clang builds. For the time being, we use the --sysroot
option just to test the correctness of the paths generated by the
driver.
Reviewers: atanasyan, dsanders, rsmith
Subscribers: jfb, tberghammer, danalbert, srhines, dschuff, cfe-commits
Differential Revision: http://reviews.llvm.org/D13340
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249137 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch moves getCompilerRT() from the clang::driver::tools namespace to
the ToolChain class. This is needed for multilib toolchains that need to
place their libraries in Clang's resource directory with a layout that is
different from the default one.
Reviewers: atanasyan, rsmith
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D13339
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249030 91177308-0d34-0410-b5e6-96231b3b80d8
logic to select an alternate target based on the executable it was
called as. For instance, if you symlink i686-linux-android-gcc to clang
and invoke it, the driver will act as though it were called with another
argument ("-target i686-linux-android"). This leads to visible effects
even in syntax-only compilations (like the ANDROID preprocessor symbol
being defined).
This behavior is not replicated for tool invocations--for instance,
clang::createInvocationFromCommandLine will not choose an alternate
target based on ArgList[0]. This means that configurations stored in
compilation databases aren't accurately replayed.
This patch separates the logic for selecting a mode flag and target from
the executable name into a new member function on ToolChain. It should
have no functional effects (but will allow other code to reuse the
target/mode selection logic).
Patch by Luke Zarko!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248592 91177308-0d34-0410-b5e6-96231b3b80d8
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.
Differential Revision: http://reviews.llvm.org/D11857
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247238 91177308-0d34-0410-b5e6-96231b3b80d8
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246814 91177308-0d34-0410-b5e6-96231b3b80d8
const char pointers. In turn, push this through Clang APIs as well,
simplifying a number of bits of code that was handling the oddities of
nullptrs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246375 91177308-0d34-0410-b5e6-96231b3b80d8
To be able to handle -Wa, options in the assembler (ClangAs), we need to
make the handling of options based on the value of the options, not direct
Arguments from the list, since the list is immutable.
No functional change in this patch, but this allows validating of -Wa,-mfpu
and friends in the same way we validate -mfpu and friends, *just* for the
assembler.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243352 91177308-0d34-0410-b5e6-96231b3b80d8
NOTE: reverts r242077 to reinstate r242058, r242065, 242067
and includes fix for OS X test failures.
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242085 91177308-0d34-0410-b5e6-96231b3b80d8
The tests were failing on OS X.
Revert "[cuda] Driver changes to compile and stitch together host and device-side CUDA code."
Revert "Fixed regex to properly match '64' in the test case."
Revert "clang/test/Driver/cuda-options.cu REQUIRES clang-driver, at least."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242077 91177308-0d34-0410-b5e6-96231b3b80d8
- Changed driver pipeline to compile host and device side of CUDA
files and incorporate results of device-side compilation into host
object file.
- Added a test for cuda pipeline creation in clang driver.
New clang options:
--cuda-host-only - Do host-side compilation only.
--cuda-device-only - Do device-side compilation only.
--cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
than once in which case one device-compilation will be done per
unique specified GPU architecture.
Differential Revision: http://reviews.llvm.org/D9509
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242058 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support and are
not toolchain- or architecture-dependent.
Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.
This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539).
Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.
This change was first submitted as r239953 and reverted in r239958.
The problem was and still is in Darwin toolchains, which get the
knowledge about target platform too late after initializaition, while
now we require this information when ToolChain::getSanitizerArgs() is
called. r240170 works around this issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240179 91177308-0d34-0410-b5e6-96231b3b80d8
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239059 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We were claiming the -f*exceptions arguments when looking for the
RTTIMode. This makes us not warn about unused arguments if compiling a C
file with -fcxx-exceptions.
This patch fixes it by not claiming the exception-related arguments at
that point.
Reviewers: rsmith, samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8507
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232860 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229801 91177308-0d34-0410-b5e6-96231b3b80d8
This reapplies r224503 along with a fix for compiling Fortran by having the
clang driver invoke gcc (see r224546, where it was reverted). I have added
a testcase for that as well.
Original commit message:
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224688 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r224503.
It broke compilation of fortran through the Clang driver. Previously
`clang -c t.f` would invoke `gcc t.f` and `clang -cc1as`, but now it
tries to call `clang -cc1 t.f` which fails for obvious reasons.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224546 91177308-0d34-0410-b5e6-96231b3b80d8
It is often convenient to use -save-temps to collect the intermediate
results of a compilation, e.g., when triaging a bug report. Besides the
temporary files for preprocessed source and assembly code, this adds the
unoptimized bitcode files as well.
This adds a new BackendJobAction, which is mostly mechanical, to run after
the CompileJobAction. When not using -save-temps, the BackendJobAction is
combined into one job with the CompileJobAction, similar to the way the
integrated assembler is handled. I've implemented this entirely as a
driver change, so under the hood, it is just using -disable-llvm-optzns
to get the unoptimized bitcode.
Based in part on a patch by Steven Wu.
rdar://problem/18909437
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224503 91177308-0d34-0410-b5e6-96231b3b80d8
Current versions of ld64 can't cope with "aarch64" being stored. I'm fixing
that, but in the transitionary period we'll need to still emit "arm64".
rdar://problem/17783765
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213852 91177308-0d34-0410-b5e6-96231b3b80d8
This commit implements the -fuse-ld= option, so that the user
can specify -fuse-ld=bfd to use ld.bfd.
This commit re-applies r194328 with some test case changes.
It seems that r194328 was breaking macosx or mingw build
because clang can't find ld.bfd or ld.gold in the given sysroot.
We should use -B to specify the executable search path instead.
Patch originally by David Chisnall.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211785 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces the definitions needed for the Windows on ARM target. Add
target definitions for both the MSVC environment and the MSVC + Itanium C++ ABI
environment. The Visual Studio definitions correspond to the definitions
provided by Visual Studio 2012.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205650 91177308-0d34-0410-b5e6-96231b3b80d8
In gcc using -Ofast forces linking of crtfastmath.o.
In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it).
My patch fixes inconsistency with gcc behaviour and also introduces few tests on it.
Patch by Zinovy Nis!
Differential Revision: http://llvm-reviews.chandlerc.com/D3114
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204742 91177308-0d34-0410-b5e6-96231b3b80d8
The integrated assembler is a feature. This makes the new flags the default
option, and the previous versions aliases. Ideally, at some point the aliases
would be entirely removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201963 91177308-0d34-0410-b5e6-96231b3b80d8
Use the verify hook rather than the compile hook to represent the
-verify-pch action, and move the exising --verify-debug-info action
into its own subclass of VerifyJobAction. Incidentally change the name
printed by -ccc-print-phases for --verify-debug-info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200938 91177308-0d34-0410-b5e6-96231b3b80d8
Using -mmacosx-version-min (etc.) on non-Darwin platforms should be a warning,
not a hard error. There is no reason to add a special check for these options
in the default toolchain. This just removes the special check and then we get
the usual -Wunused-command-line-argument warning if someone tries to use one
of these options for a target where they are not supported.
<rdar://problem/15569346>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199431 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we had bodged together some hacks mapping MachO embedded
targets (i.e. mainly ARM v6M and v7M) to the "*-*-darwin-eabi" triple.
This is incorrect in both details (they don't run Darwin and they're
not EABI in any real sense).
This commit appropriates the existing "MachO" environment for the
purpose instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199367 91177308-0d34-0410-b5e6-96231b3b80d8
getARMCPU and getLLVMArchSuffixForARM existed as very similar functions
in both ToolChain.cpp and Tools.cpp. Create a single implementation of
each in Tools.cpp, eliminate the duplicate and share via Tools.h.
Creates an 'arm' namespace in Tools.h to be used by any ARM-targetting tools.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197153 91177308-0d34-0410-b5e6-96231b3b80d8
Passing -mthumb with no explicit CPU on the command line
resulted in target CPU changing from the architecture
default to arm7tdmi. Now it does not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197151 91177308-0d34-0410-b5e6-96231b3b80d8
- krait processor currently modeled with the same features as A9.
- Krait processor additionally has VFP4 (fused multiply add/sub)
and hardware division features enabled.
- krait has currently the same Schedule model as A9
- krait cpu flag is not recognized by the GNU assembler yet,
it is replaced with march=armv7-a to avoid a lower march
from being used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196618 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the '-arch' command line option to enable the compiler-friendly
features of core-avx2 CPUs on Darwin. Pass the information along in the
target triple like Darwin+ARM does.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194907 91177308-0d34-0410-b5e6-96231b3b80d8
The thread, memory, dataflow and function sanitizers are now diagnosed if
enabled explicitly on an unsupported platform. Unsupported sanitizers which
are enabled implicitly (as part of a larger group) are silently disabled. As a
side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus
essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain.
Differential Revision: http://llvm-reviews.chandlerc.com/D1990
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193875 91177308-0d34-0410-b5e6-96231b3b80d8
Adds some Cortex-A53 strings where they were missing before.
Cortex-A57 is entirely new to clang.
Doesn't touch code only used by Darwin, in consequence of which
one of the A53 lines has been removed.
Change-Id: I5edb58f6eae93947334787e26a8772c736de6483
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193364 91177308-0d34-0410-b5e6-96231b3b80d8
It makes no sense to try and compile for arm7tdmi when we're targeting
something like gnueabihf. Although not strictly the most basic hardware
conceivable, I believe arm1176jzf-s is a reasonable compromise (that can always
be overridden explicitly if needed) since it's still in reasonably common use
unlike earlier cores.
Patch by Stephen Kelly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188796 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change turns SanitizerArgs into high-level options
stored in the Driver, which are parsed lazily. This fixes an issue of multiple copies of the same diagnostic message produced by sanitizer arguments parser.
Reviewers: rsmith
Reviewed By: rsmith
CC: chandlerc, eugenis, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1341
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188660 91177308-0d34-0410-b5e6-96231b3b80d8
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The new test case variant ensures that correct built-in defines for
little-endian code are generated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187180 91177308-0d34-0410-b5e6-96231b3b80d8
The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in clang::driver
- Fixing the autoconf build by adding option everywhere
As discussed in the review, this change includes using directives in
header files. I'll make follow up changes to remove those in favor of
name specifiers.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D975
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183989 91177308-0d34-0410-b5e6-96231b3b80d8
When choosing a default CPU, clang used to pick ARM7TDMI (which has Thumb) even
when the more restrictive armv4 triple was specified. This should fix that.
Patch by Jeroen Hofstee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183905 91177308-0d34-0410-b5e6-96231b3b80d8
Sourcery CodeBench and modern FSF Mips toolchains require a bit more
complicated algorithm to calculate headers, libraries and sysroot paths
than implemented by Clang driver now. The main problem is that all these
paths depend on a set of command line arguments additionally to a target
triple value. For example, let $TC is a toolchain installation directory.
If we compile big-endian 32-bit mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2 folder and the toolchain's linker requires
--sysroot=$TC/mips-linux-gnu/libc argument. If we compile little-endian
32-bit soft-float mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2/soft-float/el folder and the toolchain's
linker requires --sysroot=$TC/mips-linux-gnu/libc/soft-float/el argument.
1. Calculate MultiarchSuffix using all necessary command line options and
use this MultiarchSuffix to detect crtbegin.o location in the
GCCInstallationDetector::ScanLibDirForGCCTriple() routine.
2. If a user does not provide --sysroot argument to the driver explicitly,
calculate new sysroot value based on command line options. Then use this
calculated sysroot path:
a. To populate a file search paths list in the Linux::Linux() constructor.
b. To find Mips toolchain specific include headers directories
in the Linux::AddClangSystemIncludeArgs() routine.
c. To provide -–sysroot argument for a linker.
Note:
- The FSF's tree slightly differs (folder names) and is not supported
yet.
- New addExternCSystemIncludeIfExits() routine is a temporary solution.
I plan to move path existence check to the addExternCSystemInclude()
routine by a separate commit.
The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D644
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179934 91177308-0d34-0410-b5e6-96231b3b80d8
Each toolchain has a set of tools, but they are all of known types. It can
have a linker, an assembler, a "clang" (compile, analyze, ...) a non-clang
compiler, etc.
Instead of keeping a map, just have member variable for each type of tool.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177479 91177308-0d34-0410-b5e6-96231b3b80d8
The general pattern now is that Foobar::constructTool only creates tools
defined in the tools::foobar namespace and then delegates to the parent.
The remaining duplicated code is now in the tools themselves.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177368 91177308-0d34-0410-b5e6-96231b3b80d8
Jonas Hahnfeld