| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 142798
|
| |
|
|
| |
llvm-svn: 142725
|
| |
|
|
|
|
| |
-fdebug-compilation-dir. pwd[0] might not be '/' on Win32 hosts.
llvm-svn: 142720
|
| |
|
|
|
|
|
| |
closer to what GCC does, except that GCC also checks that the inodes for $PWD
and '.' match.
llvm-svn: 142633
|
| |
|
|
| |
llvm-svn: 142418
|
| |
|
|
|
|
|
|
| |
-mios-simulator-version-min.
rdar://10218700
llvm-svn: 142372
|
| |
|
|
| |
llvm-svn: 142322
|
| |
|
|
|
|
| |
We can use -mios-simulator-version-min now. rdar://10218700
llvm-svn: 142311
|
| |
|
|
|
|
|
| |
r142300 but not this patch, clang -S may emit .s files that assemblers other
than llvm-mc can't parse.
llvm-svn: 142301
|
| |
|
|
| |
llvm-svn: 142290
|
| |
|
|
|
|
| |
libgcc to the link line into a helper function.
llvm-svn: 142269
|
| |
|
|
| |
llvm-svn: 142134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'libdir' mean the actual library directory, not the GCC subdirectory of
the library directory. That was just a confusing pattern. Instead,
supply proper GCC subdirectories when scanning for various triple-based
subdirectories with a GCC installation in them. This also makes it much
more obvious how multiarch installations, which have a triple-based
prefix as well as suffix work.
Also clean up our handling of these triple-prefixed trees by using them
in both a multiarch pattern and a non-multiarch pattern whenever they
exist.
Note that this *does not* match what GCC does on Debian, the only truly
multiarch installation I've been able to get installed and test on. GCC
appears to have a bug, and ends up searching paths like
'/lib/../../lib32' which makes no sense what-so-ever. Instead, I've
tried to encode the rational logic that seems clearly intended by GCC's
pattern. GCC ends up with patterns like:
/lib/../../lib32
/usr/lib/../../lib32
/usr/lib/x86_64-linux-gnu/../..lib32
Only the last one makes any sense having a '/../..' in it, so in Clang,
that's the only one which gets a '/../..' in it.
I *think* this will fix Debian multiarch links. I'm committing without
baking this logic into our test suite so I can test on a few different
systems. If all goes well (and no one screams) I'll check in some more
comprehensive tests for multiarch behavior tomorrow.
llvm-svn: 142133
|
| |
|
|
| |
llvm-svn: 141980
|
| |
|
|
|
|
|
|
|
| |
There are now separate Triple::MacOSX and Triple::IOS values for the OS
so comparing against Triple::Darwin will fail to match those. Note that
I changed the expected output for the Driver/rewrite-objc.m test, which had
previously not been passing Darwin-specific options with the macosx triple.
llvm-svn: 141944
|
| |
|
|
|
|
|
| |
c++11. The old names are kept for backwards-compatibility. Patch by Ahmed
Charles! Names for backwards-compatible DiagGroups removed by me.
llvm-svn: 141913
|
| |
|
|
| |
llvm-svn: 141887
|
| |
|
|
| |
llvm-svn: 141795
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- This disables the system include directories, but not the compiler builtin
directories. Useful for projects that want to use things like the intrinsic
headers, but are otherwise freestanding.
- I'm willing to reconsider the option naming, I also considered providing an
explicit -builtinc (which would match -nobuiltininc), but this is more
consistent with existing options.
llvm-svn: 141692
|
| |
|
|
|
|
| |
paths). The -nostdinc behavior is now -nostdsysteminc + -nobuiltininc.
llvm-svn: 141691
|
| |
|
|
| |
llvm-svn: 141573
|
| |
|
|
|
|
|
| |
Apple only supports libc++ on OS X 10.7 and later but for the open-source
compiler that restriction doesn't make sense.
llvm-svn: 141566
|
| |
|
|
| |
llvm-svn: 141516
|
| |
|
|
| |
llvm-svn: 141487
|
| |
|
|
| |
llvm-svn: 141486
|
| |
|
|
| |
llvm-svn: 141434
|
| |
|
|
|
|
|
|
| |
Check whether the libc++ library is available when using -stdlib=libc++,
and also adjust the check for whether to link with -lgcc_s.1.
Patch by Ted Kremenek and Daniel Dunbar.
llvm-svn: 141374
|
| |
|
|
| |
llvm-svn: 141373
|
| |
|
|
| |
llvm-svn: 141344
|
| |
|
|
| |
llvm-svn: 141328
|
| |
|
|
| |
llvm-svn: 141320
|
| |
|
|
| |
llvm-svn: 141309
|
| |
|
|
| |
llvm-svn: 141308
|
| |
|
|
| |
llvm-svn: 141268
|
| |
|
|
|
|
|
| |
line options.
- <rdar://problem/10120602>, PR9631
llvm-svn: 141211
|
| |
|
|
|
|
| |
quoting code.
llvm-svn: 141205
|
| |
|
|
|
|
|
| |
reasons. However, it does seems practical to quote strings that need it.
rdar://10221951
llvm-svn: 141202
|
| |
|
|
|
|
| |
have noticed this previously, sorry.
llvm-svn: 141167
|
| |
|
|
|
|
|
| |
"versions". Currently, these are just dropped on the floor, A concrete
version number will always win out.
llvm-svn: 141159
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this saga. Teach the driver to detect a GCC installed along side Clang
using the existing InstalledDir support in the Clang driver. This makes
a lot of Clang's behavior more automatic when it is installed along side
GCC.
Also include the first test cases (more to come, honest) which test both
the install directory behavior, and the version sorting behavior to show
that we're actually searching for the best candidate GCC installation
now.
llvm-svn: 141145
|
| |
|
|
|
|
| |
function, cleaning up along the way.
llvm-svn: 141134
|
| |
|
|
|
|
| |
change.
llvm-svn: 141131
|
| |
|
|
|
|
|
| |
was assembly. Otherwise, something like -save-temps causes the integrated
assembler to warn.
llvm-svn: 141127
|
| |
|
|
|
|
|
|
|
| |
There should be a better solution to this; Michael and I are continuing
to discuss exactly what it should be. The one solution I'm very
uncomfortable with is making the FileCheck tests use a regex for each
path separator.
llvm-svn: 141126
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
installations, support them when installed directly under the system
root ('/lib/gcc/...' essentially).
With this, Clang can correctly detect and use a cross-compiling GCC
installation within a system root and use it.
Again, test cases will be coming in later commits, as I'm going to write
a few test cases that exercise nearly all of this logic.
llvm-svn: 141121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
two fundamental changes, as they ended up being interrelated.
The first is to walk from the root down through the filesystem so that
we prune subtrees which do not exist early. This greatly reduces the
filesystem traffic of this routine. We store the "best" GCC version we
encounter, and look at all of the GCC installations available.
Also, we look through GCC versions by scanning the directory rather than
using a hard-coded list of versions. This has several benefits. It makes
it much more efficient to locate a GCC installation even in the presence
of a large number of different options by simply reading the directory
once. It also future-proofs us as new GCC versions are released and
installed. We no longer have a hard coded list of version numbers, and
won't need to manually updated it. We can still filter out known-bad
versions as needed. Currently I've left in filtering for all GCC
installations prior to 4.1.1, as that was the first one supported
previously.
llvm-svn: 141120
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
GCC installation search that requires fewer filesystem operations.
Planning to implement that next as the current approcah while thorough
(and so far looks correct) does a very unfortunate number of filesystem
operations.
I'm motivated to fix this in no small part because I would like to
support a much larger space of triples and GCC versions, which would
explode the current algorithm.
llvm-svn: 141073
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
find the newest GCC available, among other goodness. It makes the entire
system much less prone to error from prefixes and/or system roots
pruning early the set of triples and GCC versions available.
Also, improve some comments and simplify the forms of some of the loops.
This causes the driver to stat directories more often than is strictly
necessary, but the alternatives which I looked at that still
accomplished this goal needed quite a bit more code and were likely not
much faster.
Test cases for this, now that our behavior here is significantly more
principled and predictable, should come tomorrow as I walk back through
VMs looking for edge cases that are missed after this.
llvm-svn: 141072
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
significantly cleaner (IMO) and more principled. We now walk down each
layer of the directory hierarchy searching for the GCC install. This
change does in fact introduce a significant behavior change in theory,
although in practice I don't know of any distro that will be impacted by
it negatively, and Debian may (untested) get slightly better through it.
Specifically, the logic now looks exhaustively for patterns such as:
/usr/lib/<triple>/gcc/<triple>
Previously, this would only be selected if there was *also*
a '/usr/lib/gcc/<triple>' directory, or if '<triple>' were the excat
DefaultHostTriple in the driver.
There is a 4-deep nested loop here, but it doesn't do terribly many
filesystem operations, as we skip at each layer of that layer's
directory doesn't exist.
There remains a significant FIXME in this logic: it would be much better
to first build up a set of candidate components for each of the four
layers with a bottom-up pruning such as this, but then select the final
installation using a top-down algorithm in order to find the newest GCC
installation available, regardless of which particular path leads to it.
llvm-svn: 141071
|
| |
|
|
|
|
|
| |
This is old leftover cruft from the days when C++ was not yet ready
for prime time.
llvm-svn: 141063
|