| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
A two-stage ThinLTO build previously failed the clang/test/Driver/hurd.c test because of a static_cast in "tools::gnutools::Linker::ConstructJob()" which wrongly converted an instance of "clang::driver::toolchains::Hurd" into that of "clang::driver::toolchains::Linux". ThinLTO would later devirtualize the "ToolChain.getDynamicLinker(Args)" call and use "Linux::getDynamicLinker()" instead, causing the test to generate a wrong "-dynamic-linker" linker flag (/lib/ld-linux.so.2 instead of /lib/ld.so)
Fixes PR45061.
Differential Revision: https://reviews.llvm.org/D75373
(cherry picked from commit 7e77cf473ac9d8f8b65db017d660892f1c8f4b75)
|
|
|
|
|
|
|
|
|
|
|
| |
Linux' current addLibCxxIncludePaths and addLibStdCxxIncludePaths
are actually almost non-Linux-specific at all, and can be reused
almost as such for all gcc toolchains. Only keep
Android/Freescale/Cray hacks in Linux's version.
Patch by sthibaul (Samuel Thibault)
Differential Revision: https://reviews.llvm.org/D69758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android does not support executable stacks.
Reviewers: srhines, pirama
Reviewed By: pirama
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53343
llvm-svn: 357197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
| |
Landed more fixes to the compiler-rt Android tests.
Original review was https://reviews.llvm.org/D53109.
llvm-svn: 346167
|
|
|
|
|
|
| |
More compiler-rt test bot breakages...
llvm-svn: 344963
|
|
|
|
|
|
|
|
|
| |
Some of the test data went missing last time I tried to submit this,
causing the tests to fail when the build did not include libc++.
Original review was https://reviews.llvm.org/D53109.
llvm-svn: 344946
|
|
|
|
|
|
| |
This reverts commit 84677d5009d613232d360fda27e6e41fb5cb6700.
llvm-svn: 344806
|
|
|
|
|
|
|
|
| |
The sanitizer builder that was broken by this should now be fixed.
Original review was https://reviews.llvm.org/D53109
llvm-svn: 344795
|
|
|
|
|
|
|
|
|
| |
Breaks some of the Android bots because they aren't expecting to need
to explicitly set -stdlib.
This reverts commit 031072f5048654b01a40f639633de1ff4e2f3dc8.
llvm-svn: 344297
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: srhines, pirama, EricWF
Reviewed By: srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53109
llvm-svn: 344296
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Android's libm does not set errno.
Reviewers: srhines, enh
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51068
llvm-svn: 340424
|
|
|
|
|
|
|
|
|
|
|
| |
This allows toolchain drivers to add multiple libc++ include paths akin
to libstdc++. This is useful in multiarch setup when some headers might
be in target specific include directory. There should be no functional
change.
Differential Revision: https://reviews.llvm.org/D45422
llvm-svn: 329748
|
|
|
|
| |
llvm-svn: 320398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here
Note: this is a recommit after a test failure took down the original (r318669)
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 320391
|
|
|
|
|
|
| |
Broke some libclang tests, so reverting for now.
llvm-svn: 318698
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.”
See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits
this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate
patch for that which is linked here
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 318669
|
|
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
|