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
This patch then adds all the usual platform-specific pieces for SystemZ:
driver support, basic target info, register names and constraints,
ABI info and vararg support. It also adds new tests to verify pre-defined
macros and inline asm, and updates a test for the minimum alignment change.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181211
Sourcery CodeBench and modern FSF Mips toolchains require a bit more
complicated algorithm to calculate headers, libraries and sysroot paths
than implemented by Clang driver now. The main problem is that all these
paths depend on a set of command line arguments additionally to a target
triple value. For example, let $TC is a toolchain installation directory.
If we compile big-endian 32-bit mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2 folder and the toolchain's linker requires
--sysroot=$TC/mips-linux-gnu/libc argument. If we compile little-endian
32-bit soft-float mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2/soft-float/el folder and the toolchain's
linker requires --sysroot=$TC/mips-linux-gnu/libc/soft-float/el argument.
1. Calculate MultiarchSuffix using all necessary command line options and
use this MultiarchSuffix to detect crtbegin.o location in the
GCCInstallationDetector::ScanLibDirForGCCTriple() routine.
2. If a user does not provide --sysroot argument to the driver explicitly,
calculate new sysroot value based on command line options. Then use this
calculated sysroot path:
a. To populate a file search paths list in the Linux::Linux() constructor.
b. To find Mips toolchain specific include headers directories
in the Linux::AddClangSystemIncludeArgs() routine.
c. To provide -–sysroot argument for a linker.
Note:
- The FSF's tree slightly differs (folder names) and is not supported
yet.
- New addExternCSystemIncludeIfExits() routine is a temporary solution.
I plan to move path existence check to the addExternCSystemInclude()
routine by a separate commit.
The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D644
llvm-svn: 179934
The concept of such a software distribution is not tied to the Linux kernel;
for example Debian GNU/Linux, Debian GNU/Hurd, and Debian GNU/kFreeBSD all
share the same source packages and generally the same user-space configuration.
llvm-svn: 178270
Each toolchain has a set of tools, but they are all of known types. It can
have a linker, an assembler, a "clang" (compile, analyze, ...) a non-clang
compiler, etc.
Instead of keeping a map, just have member variable for each type of tool.
llvm-svn: 177479
The general pattern now is that Foobar::constructTool only creates tools
defined in the tools::foobar namespace and then delegates to the parent.
The remaining duplicated code is now in the tools themselves.
llvm-svn: 177368
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174055
This patch changes the behavior of the -fsanitize=address flag, making it use the dynamic runtime library (libclang_rt.asan_osx_dynamic.dylib) instead of the static one. It also drops the CoreFoundation dependency, since the dynamic runtime doesn't need it.
llvm-svn: 173135
Truncation happens regularly when find_first_not_of returns npos,
strings long enough to trigger bug here are implausible.
No functionality change intended (ignoring absurd string lengths).
llvm-svn: 172127
to read and tell that it is a SWO -- we now descend through the
components and return a result at the first inequal component.
Also comment it a bit better and make it a total ordering by sorting on
the text of the suffix if necessary.
None of this should really be a visible change.
llvm-svn: 171219
Without this patch comparing two equal versions without patch numbers (4.7 for
example) will result in A < B and B < A.
Patch by Simon Atanasyan.
llvm-svn: 170705
* 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
ToolChains.cpp
This is in anticipation of forthcoming library path changes.
Also ...
- Fixes some inconsistencies in how the arch is passed to tools.
- Add test cases for various forms of arch flags
llvm-svn: 169505
paths
- Inherit from Linux rather than ToolChain
- Override AddClangSystemIncludeArgs and AddClangCXXStdlibIncludeArgs
to properly set include paths.
llvm-svn: 169495
Shuffling order causes the wrong one to win.
CMake didn't exhibit this problem because Clang's has *no* guards.
I'll fix this properly tomorrow when Eric and I can check both build
systems and get them to DTRT, but for now unbreak some bots by hoisting
this header.
llvm-svn: 169260
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
Unlike my previous attempt at this, this patch leaves intact the check for
whether clang can handle the input file type, and for non-Darwin toolchains it
will invoke gcc for things it cannot handle. For Darwin toolchains, the
behavior reported in pr14338 still occurs with this patch, but that is a
definite improvement from what happens currently, where it just crashes with
an assertion failure.
llvm-svn: 168505
Previously, this flag to CC1 was never exposed at the clang driver
layer, and if you happened to enable it (by being on Android or GCC 4.7
platform), you couldn't *disable* it, because there was no 'no' variant.
The whole thing was confusingly implemented.
Now, the target-specific flag processing gets the driver arg list, and
we use standard hasFlag with a default based on the GCC version and/or
Android platform. The user can still pass the 'no-' variant to forcibly
disable the flag, or pass the positive variant to clang itself to enable
the flag.
The test has also been substantially cleaned up and extended to cover
these use cases.
llvm-svn: 168473
The dynamic linker of Android does not support .ctors/.dtors.
We should emit .init_array and .fini_array regardless the
gcc version.
NOTE: This patch does not affect the ARM backend, because
it is required to generate .init_array and .fini_array
for program targeting ARM AAPCS and AEABI.
llvm-svn: 168309
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
Author: Michael J. Spencer <bigcheesegs@gmail.com>
Date: Wed Oct 10 21:48:26 2012 +0000
[Options] make Option a value type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165663 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 0464fd5e4ce2193e786e5adcab6b828f9366dae3.
llvm-svn: 165667
With this patch Bitrig can use a different c++ library without pain and
within the normal commandline parameters.
Original patch by David Hill, with lots of fixes and cleanup by me.
llvm-svn: 165430
The darwin change should be a nop since Triple::getArchTypeForDarwinArchName
doesn't know about amd64.
If things like amd64-mingw32 are to be rejected, we should print a error
earlier on instead of silently using the wrong abi.
Remove old comment that looks out of place, this is "in clang".
llvm-svn: 165368
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
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
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
llvm-svn: 162252
The hack of recognizing a -D__IPHONE_OS_VERSION_MIN_REQUIRED option
in place of -mios-simulator-version-min leaves the Darwin version
unspecified. It can be set separately with -mmacosx-version-min (which
makes no sense) or inferred to match the host version (which is unpredictable
and usually wrong). This really needs to get cleaned up, but in the
meantime, force the OS X version to 10.6 so that the behavior is sane for
the iOS simulator. Thanks for Argyrios for the patch.
<rdar://problem/11858187>
llvm-svn: 160484
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.
llvm-svn: 158694