Adds ARM Cortex-R4 and R4F support and tests in Clang. Though Cortex-R4
support was present, the support for hwdiv in thumb-mode was not defined
or tested properly. This has also been added.
llvm-svn: 234488
- Debian jessie will be released this month, add the next testing version to the list.
- RHEL7 was released last june.
- Ubuntu utopic was released last october, vivid will follow later this month.
llvm-svn: 234149
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change doesn't
modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8645
llvm-svn: 233860
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
Summary:
UBSan is now used in the same way as ASan, and is supported on
OSX and on iOS simulator. At the moment ASan and UBSan can't be used
together due to PR21112, but I hope to resolve it soon by
embedding UBSan into ASan.
Test Plan: regression test suite.
Reviewers: zaks.anna, kubabrecka
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8471
llvm-svn: 233035
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
There is no supported toolchain which provides headers / libs / object
files specific to the mips32r[3|5] and mips64r[3|5] ISA. So select "r2"
specific folders when they are available.
http://reviews.llvm.org/D7879
llvm-svn: 230611
What's going on here is that the ternary operator produces a std::string rvalue
that the StringRef points to. I'd hoped bugs like this were a thing of the past
with our asan testing but apparently this code path is only used when LLVM is
configured with a custom --with-c-include-dirs setting.
Unbreaks bootstrapping with GCC5 on Fedora (PR22625), patch by Jonathan Wakely!
llvm-svn: 229719
Add some of the missing M and R class Cortex CPUs, namely:
Cortex-M0+ (called Cortex-M0plus for GCC compatibility)
Cortex-M1
SC000
SC300
Cortex-R5
llvm-svn: 229661
Summary:
This is a more robust way of figuring out implicit deployment target
from isysroot. It also handles iphone simulator target.
Reviewers: bob.wilson, t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, cfe-commits
Differential Revision: http://reviews.llvm.org/D6939
llvm-svn: 226005
I added this check a while back but then made a note to myself that it
should be completely unnecessary since iOS always uses PIC code-gen for
aarch64. Since I could never come up with any reason why it would be
necessary, I'm just going to remove it and we'll see if anything breaks.
rdar://problem/13627985
llvm-svn: 223097
Revision 220571 removes the requirement to use -pie for tsan binaries. So remove -pie from driver.
Also s/hasZeroBaseShadow/requiresPIE/ because that is what it is used for. Msan does not have zero-based shadow, but requires pie. And in general the relation between zero-based shadow and pie is unclear.
http://reviews.llvm.org/D6318
llvm-svn: 222526
If clang was configured with a custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the equivalent configure command), the path to the custom gcc toolchain path takes precedence to the one specified by -ccc-install-dir. This causes several regression tests to fail as they will be using an unexpected path. Adding the switch --gcc-toolchain="" in each test command is not enough as the hexagon toolchain implementation in the driver is not evaluating this argument. This commit modifies the hexagon toolchain to take the --gcc-toolchain="" argument into account when deciding the toolchain path, similarly to what is already done for other targets toolchains. Additionally, the faulty regression tests are modified in order to --gcc-toolchain="" be passed to the commands.
llvm-svn: 221535
This CPU definition is redundant. The Cortex-A9 is defined as
supporting multiprocessing extensions. Remove references to this CPU.
This CPU was recently removed from LLVM. See http://reviews.llvm.org/D6057
Change-Id: I62ae7cc656fcae54fbaefc4b6976e77e694a8678
llvm-svn: 221458
Change the LC_ID_DYLIB of ASan's dynamic libraries on OS X to be set to "@rpath/libclang_rt.asan_osx_dynamic.dylib" and similarly for iossim. Clang driver then sets the "-rpath" to be the real path to where clang currently has the dylib (because clang uses the relative path to its current executable). This means if you move the compiler or install the binary release, -fsanitize=address will link to the proper library.
Reviewed at http://reviews.llvm.org/D6018
llvm-svn: 221279
The former name doesn't make sense, we are using this parameter for both .a and .dylib libraries.
No functional change.
http://reviews.llvm.org/D6040
llvm-svn: 220939
We can safely rely on the architecture to distinguish iOS device builds from
iOS simulator builds. We already have code to do that, in fact. This simplifies
some of the error checking for the option handling.
llvm-svn: 219545
This was previously only used when explicitly requested with a command line
option because it had to work with some old versions of the linker when it
was first introduced. That is ancient history now, and it should be safe to
use the correct option even when using the IPHONEOS_DEPLOYMENT_TARGET
environment variable to specify that the target is the iOS simulator.
Besides updating the test for this, I also added a few more tests for the
iOS linker options.
llvm-svn: 219527
It turns out that this was never used. Instead we just use the
IPHONEOS_DEPLOYMENT_TARGET variable for both iOS devices and simulator.
rdar://problem/18596744
llvm-svn: 219467
The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and
FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be
modeled using the same target feature, and all double-precision
operations are already disabled by the fp-only-sp target features.
llvm-svn: 218748
With this patch we call external tools for powerpc-darwin with "-arch ppc"
instead of "-arch powerpc", so as to be compatible with the cctools assembler
and ld64 linker.
Patch by Stephen Drake!
llvm-svn: 216687
modern Debian-based distributions) due to on-going multiarch madness.
It appears that when the multiarch heeader search support went into the
clang driver, it went in in a quite bad state. The order of includes
completely failed to match the order exhibited by GCC, and in a specific
case -- when the GCC triple and the multiarch triple don't match as with
i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find
the libstdc++ target-specific header files.
I assume that folks who have been using Clang on Ubuntu 32-bit systems
have been applying weird patches to hack around this. I can't imagine
how else it could have worked. This was originally reported by a 64-bit
operating system user who had a 32-bit crosscompiler installed. We tried
to use that rather than the bi-arch support of the 64-bit compiler, but
failed due to the triple differences.
I've corrected all the wrong orderings in the existing tests and added
a specific test for the multiarch triple strings that are different in
a significant way. This should significantly improve the usability of
Clang when checked out vanilla from upstream onto Ubuntu machines with
an i686 GCC installation for whatever reason.
llvm-svn: 216531
of MIPS toolchains.
The uCLibc implemented for multiple architectures. A couple of MIPS toolchains
contains both uCLibc and glibc implementation so these options allow to select
used C library.
Initially -muclibc / -mglibc (as well as -mbionic) have been implemented in gcc
for various architectures so they are not MIPS specific.
llvm-svn: 215552
from the common driver code to the corresponding `MultilibSet` declarations.
Now the `MultilibSet` can hold an optional callback function which is
responsible to return a set of include directories specific for the toolchain.
That allows to remove MIPS toolchain specific directories from
`Linux::AddClangSystemIncludeArgs` method and simplify adding new directories
in the future.
llvm-svn: 214949
Summary:
There are no tests as it is dependant upon the environment variables
XCC_C_INCLUDE_PATH & XCC_CPLUS_INCLUDE_PATH being set.
Differential Revision: http://reviews.llvm.org/D4621
llvm-svn: 214510
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
1. Revert "Add default feature for CPUs on AArch64 target in Clang"
at r210625. Then, all enabled feature will by passed explicitly by
-target-feature in -cc1 option.
2. Get "-mfpu" deprecated.
3. Implement support of "-march". Usage is:
-march=armv8-a+[no]feature
For instance, "-march=armv8-a+neon+crc+nocrypto". Here "armv8-a" is
necessary, and CPU names are not acceptable. Candidate features are
fp, neon, crc and crypto. Where conflicting feature modifiers are
specified, the right-most feature is used.
4. Implement support of "-mtune". Usage is:
-march=CPU_NAME
For instance, "-march=cortex-a57". This option will ONLY get
micro-architectural feature enabled specifying to target CPU,
like "+zcm" and "+zcz" for cyclone. Any architectural features
WON'T be modified.
5. Change usage of "-mcpu" to "-mcpu=CPU_NAME+[no]feature", which is
an alias to "-march={feature of CPU_NAME}+[no]feature" and
"-mtune=CPU_NAME" together. Where this option is used in conjunction
with -march or -mtune, those options take precedence over the
appropriate part of this option.
llvm-svn: 213353
Summary:
* Support the multilib layout used by the mips-img-linux-gnu
* Recognize mips{,64}{,el}-img-linux-gnu as being aliases of mips-img-linux-gnu
* Use the correct dynamic linker for mips-img-linux-gnu
* Make mips32r6/mips64r6 the default CPU for mips-img-linux-gnu
Subscribers: mpf
Differential Revision: http://reviews.llvm.org/D4436
llvm-svn: 212719
It reverts commits as follows:
r211866: "Driver: use GNU::Link for the Generic_GCC toolchain"
r211895: "Replace GetProgramPath("ld") with GetLinkerPath()."
r211995: "Driver: add a cygwin linker tool"
llvm-svn: 211998
This adds a linker tool for the Windows cygwin environment. This linker
invocation is significantly different from the generic ld invocation. It
requires additional parameters as well as does not accept some normal
parameters. This should fix self-hosting on Cygwin.
llvm-svn: 211995
This changes the behaviour of the driver for linking to match that of the
Generic_GCC::Assemble. The default link should use "ld" rather than "gcc" for
the linker as gcc does. This avoids the unnecessary round-tripping through gcc.
It also is much more reasonable behaviour from the user's perspective. This
should have been updated with SVN r195554 which changed the behaviour of
Generic_GCC::Assemble.
The gcc_forward test needs to be updated to mark the fact that -march is a flag
for GCC not ld. This was updated as a typo fix, but added a check for a flag
that is not a link flag.
The bindings test covers the change for testing, and thus no new test was added.
llvm-svn: 211866
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.
llvm-svn: 211785
There was already partial support for multi-arch on powerpc64le,
but the MultiarchIncludeDirs setting was missing. This patch
adds the appropriate definition, and also extends the
linux-header-search.cpp test case to verify an Ubuntu 14.04
powerpc64le tree.
llvm-svn: 211359
This corrects long-standing misuses of LLVM's internal config.h.
In most cases the public llvm-config.h header was intended and we can now
remove the old hacks thanks to LLVM r210144.
The config.h header is private, won't be installed and should no longer be
included by clang or other modules.
llvm-svn: 210145
This brings "-arch armv7m" (etc) behaviour more in line with what's expected
for developers on OS X, and allows Clang to find an "ld" (for example) in the
same directory instead of using the default /usr/bin/ld.
Unfortunately no test because it relies on the specific place Clang is running
from.
rdar://problem/16427320
llvm-svn: 209437
iterating over different library path suffixes and different library versions.
To find the most appropriate library for the given command line flags we
iterate over a set of disk paths. Before probe each path the already
detected set of multilibs are cleared. If the set of paths contains
existing paths which do not satisfy command line flags or do not contain
necessary libraries and object files at all we might lose found multilibs.
The patch updates variables which hold detected multilibs if we really find
a new multilib matches command line flags.
The patch reviewed by Jon Roelofs.
llvm-svn: 208523
Don't bother with keeping the old support for x86_64 in 6.99.23+, just
use a single range. Update test cases for the always-on --eh-frame-hdr.
llvm-svn: 208170
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
-u behaviour is apparently not portable between linkers (see cfe-commits
discussions for r204379 and r205012). I've moved the logic to IRGen,
where it should have been in the first place.
I don't have a Linux system to test this on, so it's possible this logic
*still* doesn't pull in the instrumented profiling runtime on Linux.
I'm in the process of getting tests going on the compiler-rt side
(llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test"). Once
we have tests for the full flow there, the runtime logic should get a
whole lot less brittle.
<rdar://problem/16458307>
llvm-svn: 205023
These functions are in the profile runtime. PGO comes later.
Unfortunately, there's only room for 16 characters in a Darwin section,
so use __llvm_prf_ instead of __llvm_profile_ for section names.
<rdar://problem/15943240>
llvm-svn: 204390
Remove the remaining explicit static initialization from translation
units, at least on Darwin. Instead, create a use of __llvm_pgo_runtime,
which will pull in required code from compiler-rt.
After this commit (and its pair in compiler-rt), a user can define their
own __llvm_pgo_runtime to satisfy this undefined symbol and call the
functions in compiler-rt directly.
<rdar://problem/15943240>
llvm-svn: 204379
line arguments and directories tree. The old toolchain selection heuristics
worked incorrectly when user has a reduced MIPS toolchain supports
the O32 ABI only.
Patch reviewed by Jonathan Roelofs, David Majnemer.
llvm-svn: 202873
There is no bound architecture for the dsymutil action in the driver. Trying
to check various properties of the target will cause an assertion failure
because the target doesn't get initialized without a bound architecture.
<rdar://problem/16111555>
llvm-svn: 201830
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.
This reverts r201203 (i.e. re-applying r201202 with small fixes in
unittests/CMakeLists.txtto make the build bots happy).
review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201205
This patch improves the support for picking Multilibs from gcc installations.
It also provides a better approximation for the flags '-print-multi-directory'
and '-print-multi-lib'.
review: http://llvm-reviews.chandlerc.com/D2538
llvm-svn: 201202
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.
llvm-svn: 200938
When building for i386 or x86_64 with IPHONEOS_DEPLOYMENT_TARGET set in the
environment, the toolchain correctly recognizes that the target platform is
the iOS simulator. The code in Darwin::addMinVersionArgs was not updated for
svn 197148, where isTargetIPhoneOS() was widely replaced by isTargetIOSBased().
This is kind of a strange case, though, because we probably ought to be
passing -ios_simulator_version_min to the linker, but according to the FIXME
in the code, we intentionally avoid that unless the -mios-simulator-version-min
option was used. I don't know whether it is safe to change that yet, so
for now, I am just fixing the assertion failure.
llvm-svn: 200618
libc++) when the installation is within the system root.
This doesn't really help cross compiles much, but we don't (currently)
have a great story around libc++, cross compiles, and who is responsible
for building and/or installing the libraries. However, it handles the
very common case of non-cross builds in a way entirely consistent with
GCC, so I'm hopeful this won't really hose anyone.
This is the second patch that I think should be backported to 3.4 to
give folks an easy to checkout and install working Clang+libc++
toolchain.
llvm-svn: 199769
Recent versions of the iOS simulator no longer require linking with the
crt1.o, dylib1.o, or bundle1.o files. The relevant code is now included in
libSystem for the simulator.
llvm-svn: 199696
Now instead of just looking in the system root for it, we also look
relative to the clang binary's directory. This should "just work" in
almost all cases. I've added test cases accordingly.
This is probably *very* worthwhile to backport to the 3.4 branch so that
folks can check it out, build it, and use that as their host compiler
going forward.
llvm-svn: 199632
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.
llvm-svn: 199367
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
This refactors some of the Darwin toolchain classification to give a more solid
distinction between the three primary Darwin platforms (OS X, IOS and IOS
simulator) so that a 4th choice can be added temporarily: embedded MachO
targets.
Longer term, this support will be factored out into a separate class and no
longer classified as "darwin-eabi", but the refactoring should still be useful.
llvm-svn: 197148
This is an experimental feature, where -integrated-as will be
on by default on ARM/Thumb. We aim to detect the missing features
so that the next release is stable.
Updating the ReleaseNotes, too.
Also moving the AArch64 into the same place.
llvm-svn: 197024
- 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.
llvm-svn: 196618
The integrated assembler was already the default for win32. It is now able
to handle a clang bootstrap on mingw, so make it the default.
llvm-svn: 195676
Clang still has support for running gcc for performing various stages
of a build. Right now it looks like this is used for
* Supporting Fortran in the clang driver
* Running an assembler or linker in systems we don't yet know how to
run them directly.
It looks like the gcc::Precompile is a vestige from the days when we
supported using clang for C and running gcc for c++. This patch removes it
(yes, we have no tests for it).
llvm-svn: 195586
This is currently unused by any test. The code path would still be hit
by clang on ppc, but
* PPC has not been supported on current versions of OS X
* A port of current clang to older OS X on ppc should be using
toolchains::DarwinClang.
llvm-svn: 195585
Clang knows how to use the gnu assembler directly from doing so on linux and
hurd. The existing support worked out of the box on cygwin and mingw and I was
able to bootstrap clang with it in both systems (with pending patches for the
new mingw abi, but that is independent of the assembler).
llvm-svn: 195554
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.
llvm-svn: 194907
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
llvm-svn: 193875
which doesn't use that multilib. As a consequence, fix Clang's support
for cross compiling environments that were relying on this quirk to
ensure the correct library search path ordering.
This also re-instates the new test cases from Rafael's r193528 for
cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the
existing test cases (they were no longer needed).
This solution was the result of a lot of IRC debugging and trying to
understand *exactly* what quirk was being relied upon. It took some time
for me to figure out that it was the use of 'lib32' is a multilib that
was throwing a wrench in the works.
In case you are thinking that its silly to use a multilib of 'lib' at
all, entertainingly, GCC does so as well (you can see it with the
.../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of
search paths (multilib followed by non-multilib) has observable (if
dubious) consequences. =/ Yuck.
llvm-svn: 193601
actually a MIPS-only hack to shim in random ABI directory suffixes in
numerous places throughout the toolchain's path search. It shouldn't
appear to be anything more general or useful.
llvm-svn: 193595
record what is *actually* going on here as the comments existing in the
code are confusing at best, and in places outright misleading.
The API is even more misleading. Yay.
llvm-svn: 193577
With this patch we correctly determine that ubuntu's ARM tree is not biarch
and use "lib" istead of "lib32".
Without this patch the search inside the arm tree for the crt files was failing
and we would end up trying to use the i686 ones in lib32.
llvm-svn: 193528
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
llvm-svn: 193364
multi-library path suffix.
The code calculates MIPS toolchain specific multi-lib path suffixes like
mips16/soft-float/el is moved to the separate function
findMultiLibSuffix(). This function called during GCC installation
detection and result is stored for the future using.
The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D1738
llvm-svn: 191612
This patch turns the -mv* hexagon options into aliases. We should really produce
errors for invalid versions in the driver, but this patch preserves the old
behavior for now.
llvm-svn: 191298
Instead add the ASan runtime to the linker command line so that only the ASan API functions can be undefined in the target library.
Fixes http://llvm.org/bugs/show_bug.cgi?id=17275
llvm-svn: 191076
When sysroot is not set, look for libstdc++ first on the clang install
directory. Before this change if clang was installed alongside a gcc with
the same version as the system one we would select the system libstdc++.
Unfortunately this is hard to test as only the non-sysroot case is changed.
llvm-svn: 189536
which add another wrinkle to the installation of the libstdc++ headers.
Add at least some basic testing of the weirdnesses of Gentoo's layout.
llvm-svn: 189212
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
llvm-svn: 188660
Otherwise it lists all files (e.g. shared libraries) that happen to be in the
same paths the GCC installations usually reside in.
On a x86_64 Debian 7 system with i386 multilibs.
before: clang -v 2>&1|wc -l
3059
after: clang -v 2>&1|wc -l
10
llvm-svn: 188400
Clang when linking and using a GCC installation from a GCC
cross-compiler.
This was desired already by two special case platforms (Android and
Mips), and turns out to be generally (if frustratingly) true. I've added
a substantial comment to the code clarifying the underlying assumptions
of doing actual cross compiles with Clang (or GCC for that matter!) and
help avoid further confusion here.
The end result is to realize that fully general form of PR12478 cannot
be resolved while we support existing cross-compiling GCC toolchains,
and linking with them (namely, linking against their libgcc and
libstdc++ installs). GCC installs these target libraries under
a target-specific prefix but one that may not be available within the
actual sysroot in use. When linking in this world, GCC works and Clang
should as well, but caveat emptor: DSOs from this tree must be
replicated and rpath-fixed to be found at runtime within the sysroot.
I've extended the cross compile test cases to cover these issues by
pointing them at a sysroot and actually checking the library search
paths.
llvm-svn: 187466
on the system, and report it when running the driver in verbose mode.
Without this it is essentially impossible to understand why a particular
GCC toolchain is used by Clang for libstdc++, libgcc, etc.
This also required threading a hook through the toolchain layers for
a specific toolchain implementation to print custom information under
'clang -v'. The naming here isn't spectacular. Suggestions welcome.
llvm-svn: 187427
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.
llvm-svn: 187180
There are fundamentally two different things that were getting conflated
here.
1) A bi-arch GCC toolchain install. This is not a full blown cross
compiler, but it supports targetting both 32-bit and 64-bit variants
of the same architecture using multilib OS installs and runtimes.
2) A "multiarch" Debian OS/runtime layout that lays out the libraries,
headers, etc as-if there were going to be a full blown cross compiler
even when in reality it is just a bi-arch GCC targeting two variants.
Also, these tend to use oddly "canonicalized" triples without the
vendor in them unlike the typical cross compiler runtime library
search that vanilla GCC cross compilers perform.
Now, when we mean the bi-arch nature of GCC accomplished with just
a suffix or tweak to the GCC paths, we say 'Biarch' or something
related. When we mean the Debian layout of includes and libraries, we
say multiarch or reference the multiarch triple.
In the process of reading and often renaming stuff in all these places,
also reformat with clang-format. No functionality change should be going
on here, this is just tidying up.
llvm-svn: 184632
directory for programs used by the driver is actually the standard
behavior we want to be compatible with GCC cross compilers -- it isn't
specific to SUSE or any other distro.
Also start fleshing out testing of the different cross compilation
patterns, both with a new very bare-bones tree of cross compilers and by
extending the multilib trees. Currently, we don't correctly model doing
a cross compile using the non-triple target of a bi-arch GCC install,
but I'll add support for that (and tests) next.
llvm-svn: 184499
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
llvm-svn: 183989
Javed Absar