-mx32 flag setup target environment to GNUX32 and can be used for
other 32/64-bit triplets (i386-unknown-linux, x86_64-unknown-linux) to
turn on x32 mode. Compatible with GCC -mx32 flag.
Differential Revision: http://reviews.llvm.org/D4470
llvm-svn: 212817
Summary:
The BSDs and Darwin all forward the whole 'u' group, but gcc only
forwards -u so far as I can tell. I only forward -u, since that's a
minimal change, and many people object to magically recognizing and
forwarding linker arguments.
Reviewers: chandlerc, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4304
llvm-svn: 211756
Summary:
The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or
is the default). It remains ld.so.1 for other cases.
This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008.
Differential Revision: http://reviews.llvm.org/D4273
llvm-svn: 211598
On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name
instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version).
This fixes the clang driver to pass the appropriate -dynamic-linker
setting, and adds some more tests to linux-ld.c.
llvm-svn: 211360
Call it "libclang_rt.builtins-<arch>.a" to be consistent
with sanitizers/profile libraries naming. Modify Makefile
and CMake build systems and Clang driver accordingly.
Fixes PR19822.
llvm-svn: 209474
In gcc using -Ofast forces linking of crtfastmath.o.
In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it).
My patch fixes inconsistency with gcc behaviour and also introduces few tests on it.
Patch by Zinovy Nis!
Differential Revision: http://llvm-reviews.chandlerc.com/D3114
llvm-svn: 204742
This commit is not strictly correct nor accounts for all uses (shared
objects, for example), but it allows one to test the compiler-rt library
on GNU targets.
Using this patch to run the test-suite has already shown me problems
on ARM. Since this is a Darwin-only flag, nobody is using it, so it
shouldn't be a problem.
I will need extension to deal with the shared cases, but since we're
not compiling libclang_rt.so, that's not yet applicable. Many other
problems will have to be fixed first in compiler-rt (such as removing
the 'arch' name from it and making it trully multi-arch, moving it to
the default lib directory, make both .a and .so variants, etc).
llvm-svn: 201307
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
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
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
GCC on fedora 18 ARM only uses 2 -L options. Clang prints two extra ones, but
we should not include them in the test as they are not required.
llvm-svn: 193430
-gcc-toolchain foo -> --gcc-toolchain=foo
-target foo -> --target=foo
I've added legacy aliases for the original spellings. I've updated the
canonical tests to check both spellings, and switched all of the
-gcc-toolchain usages elsewhere in the test suite to use the new one.
I've updated some of the usages of -target to the new syntax, but will
finish that in a separate entirely mechanical change once I'm sure this
won't get rolled back for some reason (It touches a *huge* number of RUN
lines in the test suite unsurprisingly).
A nice result is that the three most common flags I end up using when
doing cross compiles are all now consistent: --target=, --sysroot=, and
--gcc-toolchain=.
llvm-svn: 184408
with both -static-libgcc and -static on the commandline.
Fix a warning in the latter case due to a backwards short circuiting ||
operator in the driver. No real functionality changed here, just allows
the driver to properly consume -static-libgcc when -static is also
specified.
llvm-svn: 176429
* Look for i686-linux-android under <sysroot>/lib/gcc.
* This patch also slightly enhance the test suite for
Android GCC toolchain detection.
llvm-svn: 169557
According to Android ABI, we have to link with
libdl.so, if we are linking with non-static libgcc.
Besides, this also fixes MIPS link error of
undefined references to `_Unwind_Find_FDE' and
`dl_iterate_phdr'.
llvm-svn: 168310
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
crtfastmath.o contains routines to set the floating point flags to a faster,
unsafe mode. Linking it in speeds up code dealing with denormals significantly
(PR14024).
For now this is only enabled on linux where I can test it and crtfastmath.o is
widely available. We may want to provide a similar file with compiler-rt
eventually and/or enable it on other platforms too.
llvm-svn: 165240
1. Add mipsel-linux-android to the list of valid MIPS target triples.
2. Add <gcc install path>/mips-r2 to the list of toolchain specific path
prefixes if target is mipsel-linux-android.
The patch reviewed by Logan Chien.
llvm-svn: 165131
The Freescale SDK is based on OpenEmbedded, and this might be useful
for other OpenEmbedded-based configurations as well.
With minor modifications, patch by Tobias von Koch!
llvm-svn: 164177
Android uses the same flavour of crt*.o for PIE and non-PIE executables, and a
different one for DSOs. GNU/Linux, on the other hand, uses one set of crt*.o
for non-PIE executables, and another for both PIE executables and DSOs.
llvm-svn: 163500
This change adds detection of C++ headers and libraries paths when
building with the standalone toolchain from Android NDK. They are in a
slightly unusual place.
llvm-svn: 163109
Most of the code guarded with ANDROIDEABI are not
ARM-specific, and having no relation with arm-eabi.
Thus, it will be more natural to call this
environment "Android" instead of "ANDROIDEABI".
Note: We are not using ANDROID because several projects
are using "-DANDROID" as the conditional compilation
flag.
llvm-svn: 163088
Evgeniy Stepanov