Age | Commit message (Collapse) | Author |
|
of the target triple to stand in for the "host" triple.
Thanks to a great conversation with Richard Smith, I'm now much more
confident in how this is proceeding. In all of the places where we
currently reason about the "host" architecture or triple, what we really
want to reason about in the detected GCC installation architecture or
triple, and the ways in which that differs from the target. When we find
a GCC installation with a different triple from our target *but capable
of targeting our target* through an option such as '-m64', we want to
detect *that* case and change the paths within the GCC installation (and
libstdc++ installation) to reflect this difference.
This patch makes one function do this correctly. Subsequent commits will
hoist the logic used here into the GCCInstallation utility, and then
reuse it through the rest of the toolchains to fix the remaining places
where this is currently happening.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
inside of GCCInstallation to be a proper llvm::Triple. This is still
a touch ugly because we have to use it as a string in so many places,
but I think on the whole the more structured representation is better.
Comments of course welcome if this tradeoff isn't working for folks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148843 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I can't read Java-style 'Gcc' acronyms. ;]
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function. The logic for this, and I want to emphasize that this is the
logic for computing the *target* triple, is currently scattered
throughout various different HostInfo classes ToolChain factoring
functions. Best part, it is largely *duplicated* there. The goal is to
hoist all of that up to here where we can deal with it once, and in
a consistent manner.
Unfortunately, this uncovers more fun problems: the ToolChains assume
that the *actual* target triple is the one passed into them by these
factory functions, while the *host* triple is the one in the driver.
This already was a lie, and a damn lie, when the '-target' flag was
specified. It only really worked when the difference stemmed from '-m32'
and '-m64' flags. I'll have to fix that (and remove all the FIXMEs I've
introduced here to document the problem) before I can finish hoisting
the target-calculation logic.
It's bugs all the way down today it seems...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly. Getting the target triple wrong mostly appears to work, but messes up in subtle cases; for example, we incorrectly conclude that fwrite is actually named fwrite$UNIX2003. Also shuffles around the auto-detection code a bit to try and make it a bit more reliable. Fixes <rdar://problem/10664848>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148249 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148137 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Gnu hash is not supported by the Android loader.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148113 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147920 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
shared between lambda expressions and block literals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147917 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for the arm-linux-androideabi triple in particular.
Also use this to do a better job of selecting soft FP settings.
Patch by Evgeniy Stepanov.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147872 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Sylvestre Ledru. Fixes PR11673.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
especially nice as the Windows toolchain needs the windows header files,
and has lots of platform specific hooks in it.
To facilitate the split, hoist a bunch of file-level static helpers into
class-level static helpers. Spiff up their doxygen comments while there
as they're now more likely to be looked up via docs.
Hopefully, this will be followed by further breaking apart of the
toolchain definitions. Most of the large and complex ones should likely
live on their own. I'm looking at you Darwin. ;]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
incompatible with the MIPS ABI.
Patch by Simon Atanasyan.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146243 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
. move compiler-rt to a separate directory so the -L argument only includes compiler-rt (thanks joerg)
. build all clang subdirs
. switches the Minix platform to ELF
. normalizes toolchain invocation
Patch by Ben Gras.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146206 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146142 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dual support for compiler-rt on Linux, during bringup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146094 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146016 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dynamic_lookup for dynamic libs. Style fixes. Patch by glider@google.com
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145955 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145651 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PR11444/PR11445.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145321 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144869 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144381 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Atanasyan.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144358 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
version of Ubuntu. It has a very broken multiarch configuration, and so
we need special logic to handle it correctly. Fixing and testing this
uncovered a few other trivial issues with the logic that are fixed as
well.
I added tests to cover this as it is hard to notice if you install
recent versions of the OS.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144165 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144108 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
useful when using Clang as a system-compiler, but its harmless. When
using Clang as a cross-compiler, this can be very handy as quite a few
toolchains ship their libc headers here rather than under
'/usr/include'.
For reference, this is the beginning of my work to also make the Clang
driver more suitable as a cross-compiler.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144089 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143917 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Test cases for this and all the rest of the port are still in the works,
but will wait for a fixed computer and post 3.0 merging...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143916 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
routines on the base toolchain class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143900 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
toolchain. The logic is mostly generic already, and where possible
should be made more generic. Also, it has no impact other than to expose
a set of methods which each toolchain can then query to setup their
desired configuration. These should be available to toolchains beyond
just Linux.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the same as a directory added further down in the new logic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143897 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
looks for evidence of a multilib installation, and adds the appropriate
bits to the search paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143896 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
aren't guaranteed to live long enough otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
detection system that is providing the library paths and crt object
files.
This, modulo any bugs that need to be shaken out, resolves numerous bugs
with how we handle header paths. Here are a few that I know of:
- We no longer need to enumerate all GCC versions searched.
- OpenSUSE searched GCC versions in the wrong order.
- There were typos when selecting various patterns, etc.
- We aren't stating quite some many directories now.
- SysRoot didn't always work in a reasonable way.
I'm working on tests for this, but the tests are making me and Lit sad.
The real testing for this type of driver change is to try it out on
various distributions. I'll hit the common ones right away, and start
more thorough testing tomorrow after some sleep.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143874 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
path triples. Also order the 32-bit triples a bit more reasonably.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143873 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the detected GCC installation. This allows us to expose another aspect
of what we detected: the GCC version. This will be used shortly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143871 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will facilitate further use and recombinations of them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143869 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
directories. This way we stop at the first multiarch directory found on
the system. This achieves the real intended result of pruning
non-existent directories.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143866 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a better way. The more I think about it the more worried I am that this
hammer is simply too large. We should only be reaching out to the
filesystem when doing interesting "detection" things, not gratuitously.
Original commit message:
Start pruning down the set of flags passed to CC1 for header search.
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.
The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143865 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This cleans up the CC1 invocations, and reduces the overhead there.
We're still hammering the filesystem looking for the C++ standard
libraries though.
The only reservation I have about this policy is the case of virtualized
files inside of CC1, but it's not clear what the best way to solve that
is. The Driver consistently queries the actual filesystem to make its
decisions. Changing that would be a very large undertaking. It might be
worthwhile, but it's not an immediate goal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143864 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
edge cases and have better behavior. Specifically, we should actually
prefer the general '4.6' version string over the '4.6.1' string, as
'4.6.2' should be able to replace it without breaking rpaths or any
other place that these paths have been embedded. Debian-based
distributions are already using a path structure with symlinks to
achieve in-place upgrades for patch versions. Now our parsing reflects
this and we select the shorter paths instead of the longer paths.
A separate issue was that we would not parse a leading patch version
number even in the presence of a suffix. The above change makes this
more problematic as it would cause a suffix being added to make us treat
the entire thing as patch-version-agnostic, which it isn't. This changes
the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that
the latter has *some* patch number information. Currently, we always
bias toward the shorter and more canonical version strings. If it
becomes important we can add more Debian like rules to produce sequences
such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5',
but I'm very doubtful this will ever matter or be desirable.
I've made the tests for this logic a bit more interesting, and added
some specific tests for logic that is now different.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143841 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variable to begin with... As I'm planning to add include root
information to this object, this would have caused confusion. It didn't
even *actually* hold the include root by the time we were done with it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Michael!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
toolchain instead of merely using it in the constructor. This will allow
us to query it when building include paths as well as the file search
paths built in the constructor. I've lifted as little of it as I could
into the header file.
Eventually this will likely sink down into some of the Generic
toolchains and be used on more platforms, but I'm starting on Linux so
I can work out all the APIs needed there, where it is easiest to test
and we have the most pressing need.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143838 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
headers. As llvm-gcc is dead, and I have no idea if this ever really
worked, I think it's time for it to go. More importantly, it makes it
harder to generalize the include search logic. If someone really wants
these to work, they can set the CPLUS_INCLUDE_PATH environment variable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143836 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143816 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
actually manage the builtin header file includes as well as the system
ones.
This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.
Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.
Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143801 91177308-0d34-0410-b5e6-96231b3b80d8
|