summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a significant oversight in my move of MSVC includes to the driver:Chandler Carruth2011-11-051-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 143801
* Add two flags to the CC1 layer that I was hoping to avoid. We need toChandler Carruth2011-11-051-2/+2
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 143798
* Fix MSVC build.Michael J. Spencer2011-11-051-2/+4
| | | | llvm-svn: 143770
* Begin the migration of header search logic to the driver, starting withChandler Carruth2011-11-041-0/+269
| | | | | | | | | 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. llvm-svn: 143752
* Simplify the set of directories we look for on multiarch systems.Chandler Carruth2011-10-311-8/+2
| | | | | | | | I don't have any Debian system with one of these currently, and it seems unlikely for one to show up suddenly. We can add more patterns here if they become necessary. llvm-svn: 143346
* Fix part of PR11223 and probably a few dups as well. This teaches theChandler Carruth2011-10-311-4/+42
| | | | | | | | | | | | | | | | | | library search logic to "properly" handle multiarch installations. I've tested this on both Debian unstable and the latest Ubuntu which both use this setup, and this appears to work largely the same way as GCC does. It isn't exactly the same, but it is close enough and more principled in its behavior where it differs. This should resolve any failures to find 'crt1.o' etc on Debian-based Linux distributions. If folks find more cases where we fail, please file bugs and CC me. Test cases for all of the debian silliness are waiting both to simplify the process of merging these down into the 3.0 release, and because they're so crazy I haven't yet been able to really produce a fake tree that represents what we need to test for. I'll eventually add them though. llvm-svn: 143344
* Stop disabling integrated assembler with -static. <rdar://problem/10175391>Bob Wilson2011-10-301-7/+1
| | | | | | | The integrated assembler seems to be working pretty well for -static code now, so remove the hacks to disable it. llvm-svn: 143304
* [driver] Make the driver to link the simulator arclite lib when passing ↵Argyrios Kyrtzidis2011-10-181-3/+5
| | | | | | | | -mios-simulator-version-min. rdar://10218700 llvm-svn: 142372
* Revert r142311, -mios-simulator-version-min does not work correctly.Argyrios Kyrtzidis2011-10-181-0/+51
| | | | llvm-svn: 142322
* Remove the hack where we sniff the __IPHONE_OS_VERSION_MIN_REQUIRED define.Argyrios Kyrtzidis2011-10-171-51/+0
| | | | | | We can use -mios-simulator-version-min now. rdar://10218700 llvm-svn: 142311
* Fix a silly bug introduced in r142133.Chandler Carruth2011-10-161-2/+2
| | | | llvm-svn: 142134
* Clean up some cruft in the library path searching logic by makingChandler Carruth2011-10-161-27/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '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
* Fix the CXX_INCLUDE_ROOT case that was out of date with ScanLibDirForGCCTriple.Rafael Espindola2011-10-141-1/+1
| | | | llvm-svn: 141980
* Use Triple.isOSDarwin() instead of comparing against Triple::Darwin.Bob Wilson2011-10-141-1/+1
| | | | | | | | | 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
* Add triple for RHEL 5 to the libpath collecting logic.Benjamin Kramer2011-10-131-0/+1
| | | | llvm-svn: 141887
* Partially revert r141374: allow use of libc++ prior to Mac OS X 10.7.Bob Wilson2011-10-101-5/+0
| | | | | | | 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
* Fix "Uninitialized" warnings.NAKAMURA Takumi2011-10-081-3/+3
| | | | llvm-svn: 141487
* WhitespaceNAKAMURA Takumi2011-10-081-1/+1
| | | | llvm-svn: 141486
* Clang driver changes for iOS 5.0 and OS X Lion support.Bob Wilson2011-10-071-3/+34
| | | | | | | | 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
* Use StringSwitch. Thanks for Chandler for the suggestion.Bob Wilson2011-10-071-41/+20
| | | | llvm-svn: 141344
* Rearrange for readability. No functional change.Bob Wilson2011-10-061-3/+4
| | | | llvm-svn: 141309
* Add a missing check for cortex-a9.Bob Wilson2011-10-061-1/+2
| | | | llvm-svn: 141308
* Use the InstalledDir correctly, and test it correctly as well. =/ ShouldChandler Carruth2011-10-051-1/+1
| | | | | | have noticed this previously, sorry. llvm-svn: 141167
* Teach Clang to cope with GCC installations that have unusual patchChandler Carruth2011-10-051-3/+5
| | | | | | | "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159
* Implement the feature I was originally driving toward when I startedChandler Carruth2011-10-051-0/+1
| | | | | | | | | | | | | | 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
* Hoist the other messy part out of an inner loop and into a helperChandler Carruth2011-10-041-43/+45
| | | | | | function, cleaning up along the way. llvm-svn: 141134
* Hoist the first chunk of this into a helper function. No functionalityChandler Carruth2011-10-041-55/+68
| | | | | | change. llvm-svn: 141131
* Fix Windows+MinGW which introduces noise into path separators.Chandler Carruth2011-10-041-1/+5
| | | | | | | | | 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
* Now that multiple prefixes are much cheaper to search for GCCChandler Carruth2011-10-041-0/+1
| | | | | | | | | | | | | 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
* Rework the search for a GCC installation still further. This combinesChandler Carruth2011-10-041-50/+85
| | | | | | | | | | | | | | | | | | | | | | 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
* Add a comment explaining that I have a better plan for implementing theChandler Carruth2011-10-041-0/+2
| | | | | | | | | | | | | 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
* Invert the loop for detecting installed GCC trees. This make the loopChandler Carruth2011-10-041-36/+19
| | | | | | | | | | | | | | | | | | | 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
* Fuse the two halves of the GCC installation detection. This isChandler Carruth2011-10-041-54/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Factor the data apart from the logic of locating various GCCChandler Carruth2011-10-041-45/+63
| | | | | | | | | | | | | | | | | | | | | | | | | installations. This first selects a set of prefixes and a set of compatible triples for the current architecture. Once selected, we drive the search with a single piece of code. This code isn't particularly efficient as it stands, but its only executed once. I'm hoping as I clean up the users of this information, it will also slowly become both cleaner and more efficient. This also changes the behavior slightly. Previously, we had an ad-hoc list of prefixes and triples, and we only looked for some triples beneath specific prefixes and vice versa. This has led to lots of one-off patches to support triple X, or support lib dir Y. Even without going to a fully universal driver, we can do better here. This patch makes us always look first in either 'lib32' or 'lib64' on 32- or 64-bit hosts (resp.). However, we *always* look in 'lib'. Currently I have one lingering problem with this strategy. We might find a newer or better GCC version under a different (but equally compatible) triple. Fundamentally, this loop needs to be fused with the one below. That's my next patch. llvm-svn: 141056
* Refactor the detection of a GCC installation into a helper class. ThisChandler Carruth2011-10-031-157/+191
| | | | | | | | | | | | | is designed to allow the detection to record more rich information about the installation than just a single path. Mostly, the functionality remains the same. This is primarily a factoring change. However, the new factoring immediately fixes one issue where on ubuntu we didn't walk up enough layers to reach the parent lib path. I'll have a test tree for that once I finish making the Ubuntu tree work reasonably. llvm-svn: 141011
* Enable generic multilib support on 32bit hosts. Previously this was onlyChandler Carruth2011-10-031-13/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
* Teach the logic for locating an installed GCC about the system root.Chandler Carruth2011-10-031-6/+12
| | | | | | | | | | | | | | | | | This requires fixing a latent bug -- if we used the default host triple instead of an autodetected triple to locate GCC's installation, we didn't go back and fix the GCC triple. Correct that with a pile of hacks. This entire routine needs a major refactoring which I'm saving for a subsequent commit. Essentially, the detection of the GCC triple should be hoisted into the same routine as we locate the GCC installation: the first is intrinsically tied to the latter. Then the routine will just return the triple and base directory. Also start to bring the rest of the library search path logic under test, including locating crtbegin.o. Still need to test the multilib and other behaviors, but there are also bugs in the way of that. llvm-svn: 140995
* Add initial support for applying the sysroot to library search paths.Chandler Carruth2011-10-031-5/+6
| | | | | | | | | | | | | | | | | | | | This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
* Rework the selection of builtin library search paths on Linux toChandler Carruth2011-10-031-33/+44
| | | | | | | | | | | | | | | | | | | | | | | | | precisely match the pattern and logic used by the GCC driver on Linux as of a recent SVN checkout. This happens to follow a *much* more principled approach. There is a strict hierarchy of paths examined, first with multilib-suffixing, second without such suffixing. Any and all of these directories which exist will be added to the library search path when using GCC. There were many places where Clang followed different paths, omitted critical entries, and worst of all (in terms of challenges to debugging) got the entries in a subtly wrong order. If this breaks Clang on a distro you use, please let me know, and I'll work with you to figure out what is needed to work on that distro. I've checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora, and Gentoo. I'll be testing it on those as well as Debian stable and unstable and ArchLinux. I may even dig out a Slackware install. No real regression tests yet, those will follow once I add enough support for sysroot to simulate various distro layouts in the testsuite. llvm-svn: 140981
* Simplify this through the power of the ternary operator.Chandler Carruth2011-10-021-18/+4
| | | | llvm-svn: 140965
* Consolidate the currently bizarre 32/64 multilib selection logic a bit.Chandler Carruth2011-10-021-19/+19
| | | | llvm-svn: 140964
* Revert r140604: "Let -B work for ld paths on Linux."Chandler Carruth2011-10-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This patch may do what it describes, it may not. It's hard to tell as its completely unclear what this is supposed to do. There are also no test cases. More importantly, this seems to have broken lots of linker invocations on multilib Linux systems. The manual pages for 'ld' on Linux mention translating a '=' at the beginning of the path into a *configure time* sysroot prefix (this is, I believe, distinct from the --sysroot flag which 'ld' also can support). I tested this with a normal binutils 'ld', a binutils 'ld' with the sysroot flag enabled, and gold with the sysroot flag enabled, and all of them try to open the path '=/lib/../lib32', No translation occurs. I think at the very least inserting an '=' needs to be conditioned on some indication that it is supported and desired. I'm also curious to see what toolchain and whan environment cause it to actually make a difference. I'm going to add a test case for basic sanity of Linux 'ld' invocations from Clang in a follow-up commit that would have caught this. llvm-svn: 140908
* Driver: use correct search paths for multilibPeter Collingbourne2011-09-291-2/+2
| | | | llvm-svn: 140782
* Driver: Fix two bad typos that were breaking the buildbots.Benjamin Kramer2011-09-281-1/+1
| | | | llvm-svn: 140682
* [driver] If no OSX or iOS target has been specified and we're compiling for Chad Rosier2011-09-281-0/+6
| | | | | | | armv7, go ahead as assume we're targeting iOS. rdar://10147774 llvm-svn: 140668
* Check for GCC paths that have the target triple in them. This is required ↵David Chisnall2011-09-271-20/+30
| | | | | | for a lot of cross-compile toolchains. Also add some slightly better support for -B. llvm-svn: 140645
* Let -B work for ld paths on Linux.David Chisnall2011-09-271-2/+2
| | | | llvm-svn: 140604
* Switch assert(0/false) llvm_unreachable.David Blaikie2011-09-231-5/+5
| | | | llvm-svn: 140367
* For i386 kext fallback to llvm-gcc, search paths for several Darwin versions.Bob Wilson2011-09-201-5/+11
| | | | | | | | | This replaces the hack to read UNAME_RELEASE from the environment when identifying the OS version on Darwin, and it's more flexible. It's also horribly ugly, but at least this consolidates the ugliness to touch less of the code so that it will be easier to rip out later. llvm-svn: 140187
* [driver] Default to arm mode when using the integrated assembler.Chad Rosier2011-09-201-4/+6
| | | | | | rdar://10125227 llvm-svn: 140179
OpenPOWER on IntegriCloud