| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12893
llvm-svn: 248298
|
|
|
|
|
|
|
|
|
|
| |
* Only the last of the --cuda-host-only/--cuda-device-only options has effect.
* CudaHostAction always wraps host-side compilation now.
* Fixed printing of empty action lists.
Differential Revision: http://reviews.llvm.org/D12892
llvm-svn: 248297
|
|
|
|
| |
llvm-svn: 248100
|
|
|
|
|
|
|
| |
Leaving it unset can make the triple look confusing, especially
when using -m32 or -m64.
llvm-svn: 248005
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12541
llvm-svn: 247924
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 246814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current implementation tries to guess which Action will result in a
job which needs to incorporate device-side GPU binaries. The guessing
was attempting to work around the fact that multiple actions may be
combined into a single compiler invocation. If CudaHostAction ends up
being combined (and thus bypassed during action list traversal) no
device-side actions it pointed to were processed. The guessing worked
for most of the usual cases, but fell apart when external assembler
was used.
This change removes the guessing and makes sure we create and pass
device-side jobs regardless of how the jobs get combined.
* CudaHostAction is always inserted either at Compile phase or the
FinalPhase of current compilation, whichever happens first.
* If selectToolForJob combines CudaHostAction with other actions, it
passes info about CudaHostAction up to the caller
* When it sees that CudaHostAction got combined with other actions
(and hence will never be passed to BuildJobsForActions),
BuildJobsForActions creates device-side jobs the same way they would
be created if CudaHostAction was passed to BuildJobsForActions
directly.
* Added two more test cases to make sure GPU binaries are passed to
correct jobs.
Differential Revision: http://reviews.llvm.org/D11280
llvm-svn: 246174
|
|
|
|
| |
llvm-svn: 244791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
noticed until now.
The code for setting up the driver's InstalledDir didn't respect
-no-canonical-prefixes. Because of this, there are a few places in the
driver where we would unexpectedly form absolute paths, notably when
searching for and finding GCC installations to use, etc. The fix is
straightforward, and I've added this path to '-v' both so we can test it
sanely and so that it will be substantially more obvious the next time
someone has to debug something here.
Note that there is another bug that we don't actually *canonicalize* the
installed directory! I don't really want to fix that because I don't
have a realistic way to test the usage of this mode. I suspect that
folks using the shared module cache would care about getting this right
though, and so they might want to address it. I've left the appropriate
FIXMEs so that it is clear what to change, and I've updated the test
code to make it clear what is happening here.
llvm-svn: 244065
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11575
llvm-svn: 243479
|
|
|
|
|
|
|
|
|
|
|
|
| |
Host-only cuda compilation does produce valid host object
file and in some cases users do want to proceed on to the linking phase.
The change removes special case that stopped compilation pipeline at
the Assembly phase. Device-side compilation is still stopped early
by the types::getCompilationPhases().
Differential Revision: http://reviews.llvm.org/D11573
llvm-svn: 243478
|
|
|
|
|
|
|
|
|
| |
Also rename XCore (the toolchain) to XCoreToolChain since XCore is
also a namespace for its tools.
Differential Revision: http://reviews.llvm.org/D10609
llvm-svn: 243279
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11310
llvm-svn: 242718
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11273
llvm-svn: 242698
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We can enable warnings after that -w, so the patch might not be 100%
correct.
The problem that triggered this is: we have some amount of tests that
expect 0 warnings (including unit tests for -w), but -w ends up not fully
silencing everything.
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11322
llvm-svn: 242606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a minimal toolchain, which sets the integrated assembler as default,
and uses lld for linking.
Reviewers: arsenm, mcrosier
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10700
llvm-svn: 242601
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CUDA code.
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
llvm-svn: 242085
|
|
|
|
|
|
|
|
|
|
| |
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."
llvm-svn: 242077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CUDA code.
- 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
llvm-svn: 242058
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11105
llvm-svn: 241934
|
|
|
|
|
|
|
| |
Similarly to r231989, the driver arguments can be quite helpful in
diagnosing a crash.
llvm-svn: 241786
|
|
|
|
|
|
|
|
|
| |
Until somebody writes the code for it, be loud about the fact that
it's not implemented yet.
Differential Revision: http://reviews.llvm.org/D11020
llvm-svn: 241708
|
|
|
|
|
|
| |
Add a test for ppc64(le), which wasn't handled before.
llvm-svn: 241528
|
|
|
|
|
|
|
|
|
|
|
| |
We had a strange relationship here where we made a list of Jobs
inherit from a single Job, but there weren't actually any places where
this arbitrary nesting was used or needed.
Simplify all of this by removing Job entirely and updating all of the
users to either work with a JobList or a single Command.
llvm-svn: 241310
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No more hardcoded paths: clang will use -sysroot as gcc root location if
provided. Otherwise, it will search for gcc on the path. If not found it
will use the driver installed location.
http://reviews.llvm.org/D5268
Patch by Ruben Van Boxem, Martell Malone, Yaron Keren.
Reviewed by Reid Kleckner.
llvm-svn: 241241
|
|
|
|
| |
llvm-svn: 241106
|
|
|
|
|
|
|
|
|
| |
Nothing was hand edited afterward except a few literal strings
and comments that were poorly broken.
Differential Revision: http://reviews.llvm.org/D10689
llvm-svn: 240791
|
|
|
|
|
|
|
| |
To match the '-ccc-print-phases' command-line flag.
Also make two more 'for' loops range-based. NFC
llvm-svn: 240680
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10738
llvm-svn: 240674
|
|
|
|
| |
llvm-svn: 240545
|
|
|
|
| |
llvm-svn: 240476
|
|
|
|
|
|
| |
by pointer) from ParseArgs
llvm-svn: 240349
|
|
|
|
| |
llvm-svn: 240237
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is unfortunate, but would let us land http://reviews.llvm.org/D10467,
that makes ToolChains responsible for computing the set of sanitizers
they support.
Unfortunately, Darwin ToolChains doesn't know about actual OS they
target until ToolChain::TranslateArgs() is called. In particular, it
means we won't be able to construct SanitizerArgs for these ToolChains
before that.
This change removes SanitizerArgs::needsLTO() method, so that now
ToolChain::IsUsingLTO(), which is called very early, doesn't need
SanitizerArgs to implement this method.
Docs and test cases are updated accordingly. See
https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we
start all these.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10560
llvm-svn: 240170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change passes through C and assembler jobs to Movidius tools by
constructing commands which are the same as ones produces by the examples
in the SDK. But rather than reference MV_TOOLS_DIR to find tools,
we will assume that binaries are installed wherever the Driver would
find its native tools. Similarly, this change assumes that -I options
will "just work" based on where SDK headers get installed, rather than
baking into the Driver some magic paths.
Differential Revision: http://reviews.llvm.org/D10440
llvm-svn: 240134
|
|
|
|
| |
llvm-svn: 239834
|
|
|
|
|
|
|
| |
Reverting until it's easier to use this in a real-world build, e.g.
when the linker can handle it.
llvm-svn: 239656
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were adding an extra "-mlinker-version" argument to the invocation
based on a value inferred from "ld -v". This is set by the build
systems to either a sane value or an empty string (e.g. for custom
built ld), which we don't want to pass on.
No test really possible because the value depends on both host system
and how CMake was invoked.
llvm-svn: 239633
|
|
|
|
|
|
|
|
|
| |
Removed comment in Driver::ShouldUseClangCompiler implying that there
was an opt-out ability at that point - there isn't.
Differential Revision: http://reviews.llvm.org/D10246
llvm-svn: 239608
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10214
llvm-svn: 239537
|
|
|
|
|
|
|
|
|
| |
This matches the cl.exe behavior (tested with 18.00.31101). In order to
specify an output file for /P, use the /Fi option instead.
Differential Revision: http://reviews.llvm.org/D10313
llvm-svn: 239393
|
|
|
|
|
|
|
| |
We already have Args->filtered(...) which is a drop-in range-for
replacement.
llvm-svn: 239381
|
|
|
|
|
|
|
|
| |
No documentation yet; the linker needs more work.
Differential Revision: http://reviews.llvm.org/D10270
llvm-svn: 239213
|
|
|
|
| |
llvm-svn: 239038
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9939
llvm-svn: 238225
|
|
|
|
|
|
|
|
|
| |
Before this patch, passing a non-existent absolute path to clang-cl would cause
stat'ing of impossible paths. For example, `clang-cl -c d:\adsfasdf.txt` would
cause a stat of
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIBd:\asdfadsf.cc
llvm-svn: 235787
|
|
|
|
|
|
|
|
|
| |
Currently if you use -mmacosx-version-min or -mios-version-min without
specifying a version number, clang silently sets the minimum version to
"0.0.0". This is almost certainly not what was intended, so it is better
to report it as an error. rdar://problem/20433945
llvm-svn: 234270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add Tool and ToolChain support for clang to target the NaCl OS using the NaCl
SDK for x86-32, x86-64 and ARM.
Includes nacltools::Assemble and Link which are derived from gnutools. They
are similar to Linux but different enought that they warrant their own class.
Also includes a NaCl_TC in ToolChains derived from Generic_ELF with library
and include paths suitable for an SDK and independent of the system tools.
Differential Revision: http://reviews.llvm.org/D8590
llvm-svn: 233594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that CloudABI's target information and header search logic for Clang
has been submitted, the only thing that remains to be done is adding
support for CloudABI's linker.
CloudABI uses Binutils ld, although there is some work to use lld
instead. This means that this code is largely based on what we use on
FreeBSD. There are some exceptions, however:
- Only static linking is performed. CloudABI does not support any
dynamically linked executables.
- CloudABI uses compiler-rt, libc++ and libc++abi unconditionally. Link
in these libraries instead of using libgcc_s, libstdc++, etc.
- We must ensure that the .eh_frame_hdr is present to make C++
exceptions work properly.
Differential Revision: http://reviews.llvm.org/D8250
llvm-svn: 233269
|