| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also comes with a cmake cache for building the runtime bits:
$ cmake <normal cmake flags> \
-DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
-C /path/to/clang/cmake/caches/BaremetalARM.cmake \
/path/to/llvm
https://reviews.llvm.org/D33259
llvm-svn: 303873
|
| |
|
|
|
|
|
|
| |
This is because -print-multi-lib depends on them being flags for correctness.
Fixes a case of this in the arm-android multilib selection logic.
llvm-svn: 302207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add support for armv6hl-suse-linux-gnueabi and armv7hl-suse-linux-gnueabi triples used by openSUSE/SUSE.
Reviewers: cfe-commits, rovka, compnerd, rengolin
Reviewed By: rengolin
Subscribers: aemerson, rengolin, bkramer, chandlerc
Differential Revision: https://reviews.llvm.org/D32347
llvm-svn: 300969
|
| |
|
|
|
|
|
|
| |
While at it, extend test for FreeBSD and check for -lrt iff on Linux.
Differential Revision: https://reviews.llvm.org/D30087
llvm-svn: 300689
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Pass Cpu/Arch options to assembler for AArch64 with no-integrated-as.
This fixes PR20019.
Reviewers: richard.barton.arm, kristof.beyls, rengolin
Reviewed By: rengolin
Subscribers: srhines, pirama, aemerson, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D32132
llvm-svn: 300571
|
| |
|
|
|
|
|
|
|
|
|
| |
The config-*triple* file handling isn't tolerant of
leading/trailing whitespace, making it not terribly
obvious when a single extraneous tab/space/etc will
cause the override to be ignored. This patch simply
trims the lines to ensure that it is tolerant of
whitespace.
llvm-svn: 300328
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change depends on D31381 where we change the implementation to use
sanitizer_common provided atomic operations library.
Fixes http://llvm.org/PR32274.
Reviewers: pelikan, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31382
llvm-svn: 298835
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that XRay doesn't require a runtime dependency on a C++ standard
library, we remove that dependency from the clang linker flags.
Reviewers: saugustine, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31313
llvm-svn: 298670
|
| |
|
|
|
|
| |
This function already does the very same thing.
llvm-svn: 297271
|
|
|
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
|
