| Age | Commit message (Collapse) | Author |
|---|
|
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@144800 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a partial revert of r143846. While cleaning up after a crash is
probably a good idea, we were also deleting .d files if the compilation failed
due to invalid input, which is not the desired behavior. The test is XFAIL'd
until the cleanup code can be reworked to do the right thing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144590 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
|
|
diagnostics to a file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144339 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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144002 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143962 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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143856 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and prevent the diagnostic preprocessor run from writing a depfile.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143846 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
|
|
obviously only used during compilation.
rdar://10386708
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143813 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
|
|
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.
There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.
Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143798 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143778 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143770 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143752 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as the system include interface before I start adding implementations of
it to individual ToolChain implementations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143751 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
structs. Original behavior can be restored using -fno-limit-debug-info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143733 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://10383444
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143732 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handling logic of the generic ToolChain. This flag, despite its name,
has *nothing* to do with the GCC flag '-nostdlib' that relates
(exclusively) to the linking behavior. It is a most unfortunate name in
that regard...
It is used to tell InitHeaderSearch.cpp *which* set of C++ standard
library header search paths to use -- those for libstdc++ from GCC's
installation, or those from a libc++ installation. As this logic is
hoisted out of the Frontend, and into the Driver as part of this
ToolChain, the generic method will be overridden for the platform, where
it can implement this logic directly. As such, hiding the CC1 option
passing in the generic space is a natural fit despite the odd naming.
Also, expand on the comments to clarify whats going on, and tidy up the
Tools.cpp code now that its simpler.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143687 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
implementation in the driver. This cleans up the signature and semantics
of the include flag adding component of the toolchain. Another step to
ready it for holding all the InitHeaderSearch logic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the rest of the mess in InitHeaderSearch.cpp. We could hoist it into the
driver profitably, removing more noise from the driver -> frontend
communication.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143685 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and the C++ include management routine from the proper place when
forming preprocessor options in the driver. This is the first step to
teaching the driver to manage all of the header search paths. Currently,
these methods remain just stubs in the abstract toolchain. Subsequent
patches will flesh them out with implementations for various toolchains
based on the current code in InitHeaderSearch.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arguments that caused clang to crash.
rdar://8314451
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143573 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The -g and --gdwarf2 options are currently synonyms to the Darwin assembler.
But clang itself does not recognize --gdwarf2, so if we want to experiment
with using clang, with its integrated assembler, to replace the default
assembler, it is necessary to use -g. <rdar://problem/10349486>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143533 91177308-0d34-0410-b5e6-96231b3b80d8
|
