| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
|
|
|
|
|
|
|
|
|
|
| |
paths on MingW.
Patch by Mateusz Mikuła.
Differential Revision: https://reviews.llvm.org/D29464
llvm-svn: 297005
|
|
|
|
| |
llvm-svn: 291133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For the most part this is straightforward: Just add a CudaInstallation
object to the MSVC and MinGW toolchains.
CudaToolChain has to override computeMSVCVersion so that
Clang::constructJob passes the right version flag to cc1. We have to
modify IsWindowsMSVC and friends in Clang::constructJob to be true when
compiling CUDA device code on Windows for the same reason.
Depends on: D28319
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28320
llvm-svn: 291131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Will re-apply after llvm 3.8 is branched.
Original commit message:
Driver: fallback to the location of clang if no sysroot,
hard coding /usr makes little sense for mingw-w64.
If we have portable toolchains having /usr breaks that.
If the clang we use is in /usr/bin or /usr/sbin etc this will
still detect as though it was hard coded to /usr
This makes the most sense going forward for mingw-w64 toolchains
on both linux and mac
llvm-svn: 257468
|
|
|
|
| |
llvm-svn: 253899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hard coding /usr makes little sense for mingw-w64.
If we have portable toolchains having /usr breaks that.
If the clang we use is in /usr/bin or /usr/sbin etc this will
still detect as though it was hard coded to /usr
This makes the most sense going forward for mingw-w64 toolchains
on both linux and mac
Differential Revision: http://reviews.llvm.org/D14164
llvm-svn: 253898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we want to use mingw-w64 and clang with compiler-rt we should not
need to have libgcc installed. This fixes finding includes when libgcc
is not installed
Reviewers: yaron.keren
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11808
llvm-svn: 244902
|
|
|
|
|
|
|
|
| |
Generic_GCC::GCCVersion
similar to the way Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple works.
llvm-svn: 243153
|
|
|
|
|
|
| |
Thanks to Richard Smith for pointing this out!
llvm-svn: 243144
|
|
|
|
|
|
| |
directory structure. Try to make mingw toolchain resilient to such surprises.
llvm-svn: 243105
|
|
|
|
|
|
|
|
| |
Address Richard Smith comments: remove the trailing seperator from the Arch
variable, implement six mingw_* trees under tools/clangtest/Driver/Inputs
and merge linux and Windows tests into a universal test that uses these trees.
llvm-svn: 243098
|
|
|
|
|
|
|
|
|
|
| |
Now clang should be able to use compiler-rt and libc++ on mingw.
Based on a patch by Martell Malone.
Differential Revision: http://reviews.llvm.org/D11237
llvm-svn: 242905
|
|
|
|
|
|
|
|
| |
It should now support three mingw distributions running on Windows
and three Linux distributions. The include directories for each are
listed in the comments.
llvm-svn: 242766
|
|
|
|
| |
llvm-svn: 242667
|
|
|
|
| |
llvm-svn: 242662
|
|
|
|
|
|
| |
Thanks to Thomas Pochtrager for testing this!
llvm-svn: 242660
|
|
|
|
|
|
| |
Thanks to Ismail Donmez for testing and to Joerg Sonnenbergerþ for his comments.
llvm-svn: 242150
|
|
|
|
| |
llvm-svn: 241594
|
|
|
|
| |
llvm-svn: 241432
|
|
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
|