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
architecture; this was happening for tools such as lipo and dsymutil.
Also, if no -arch option has been specified, set the architecture based
on the TC default.
rdar://11329656
llvm-svn: 155730
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.
The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.
Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.
This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.
llvm-svn: 154176
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
llvm-svn: 152141
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
Debian multiarch libraries, this should in theory add support for those
platform's header search rules. I don't have a system to check this
with, so review appreciated. I've added the corresponding tests
referring to the debian multiarch tree.
We are starting to have a relatively completely tested Linux platform
for header search and library search, with several interesting
peculiarities. We should point people at the debian_multiarch_tree when
suggesting new tests. Folks with Debian systems that can check this for
correctness, it would be much appreciated. The missing chunks I know of
are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and
64-bit variants of platforms, and the MIPS and ARM Debian toolchains.
llvm-svn: 151484
Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added
64-bit support. I just added one other place where powerpc64-linux-gnu
was missing (we only had powerpc64-unknown-linux-gnu).
I've also added a tree to test out the debian multiarch stuff. I don't
use debian regularly, so I'm not certain this is entirely accurate. If
anyone wants to check it against a debian system and fix any
inaccuracies, fire away. This way at least folks can see how this is
*supposed* to be tested.
It'd be particularly good to get the Debian MIPS toolchains tested in
this way.
llvm-svn: 151482
world on Solaris 11 for both x86 and x86-64 using the built-in assembler and
Solaris (not GNU) ld, however it currently relies on a hard-coded GCC location
to find crtbegin.o and crtend.o, as well as libgcc and libgcc_eh.
llvm-svn: 150580
And remove HAVE_CLANG_CONFIG_H, now that the header is generated
in the autoconf build, too.
Reverts r149571/restores r149504, now that config.h is generated
correctly by LLVM's configure in all build configurations.
llvm-svn: 150487
that just uses the new toolchain probing logic. This fixes linking with -m32 on
64 bit systems (the /32 dir was not being added to the search).
llvm-svn: 149652
And remove HAVE_CLANG_CONFIG_H, now that the header is generated
in the autoconf build, too. (clang r149497 / llvm r149498)
Also include the config.h header after all other headers, per
the LLVM coding standards.
It also turns out WindowsToolChain.cpp wasn't using the config
header at all, so that include's just deleted now.
llvm-svn: 149504
The Darwin toolchain constructor was assuming that all Darwin triples would
have an OS string starting with "darwin". Triples starting with "macosx"
would misinterpret the version number, and "ios" triples would completely
miss the version number (or worse) because the OS name is not 6 characters
long. We lose some sanity checking of triple strings here, since the
Triple.getOSVersion function doesn't do all the checking that the previous
code did, but this still seems like a step in the right direction.
llvm-svn: 149422
driver based on discussions with Doug Gregor. There are several issues:
1) The patch was not reviewed prior to commit and there were review comments.
2) The design of the functionality (triple-prefixed tool invocation)
isn't the design we want for Clang going forward: it focuses on the
"user triple" rather than on the "toolchain triple", and forces that
bit of state into the API of every single toolchain instead of
handling it automatically in the common base classes.
3) The tests provided are not stable. They fail on a few Linux variants
(Gentoo among them) and on mingw32 and some other environments.
I *am* interested in the Clang driver being able to invoke
triple-prefixed tools, but we need to design that feature the right way.
This patch just extends the previous hack without fixing the underlying
problems with it. I'm working on a new design for this that I will mail
for review by tomorrow.
I am aware that this removes functionality that NetBSD relies on, but
this is ToT, not a release. This functionality hasn't been properly
designed, implemented, and tested yet. We can't "regress" until we get
something that really works, both with the immediate use cases and with
long term maintenance of the Clang driver.
For reference, the original commit log:
Keep track of the original target the user specified before
normalization. This used to be captured in DefaultTargetTriple and is
used for the (optional) $triple-$tool lookup for cross-compilation.
Do this properly by making it an attribute of the toolchain and use it
in combination with the computed triple as index for the toolchain
lookup.
llvm-svn: 149337
Chandler Carruth