summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
* Search for libstdc++.dylib in llvm-gcc's files on darwin10. rdar://10419079Bob Wilson2011-11-111-0/+5
| | | | llvm-svn: 144381
* Add Linux multiarch include directories for mips/mipsel. Patch from Simon ↵Eli Friedman2011-11-111-0/+10
| | | | | | Atanasyan. llvm-svn: 144358
* Add top-level driver option '--serialize-diagnostics' for serialize compiler ↵Ted Kremenek2011-11-111-0/+6
| | | | | | diagnostics to a file. llvm-svn: 144339
* Fix an issue that Duncan discovered on a specific (no longer current)Chandler Carruth2011-11-092-9/+8
| | | | | | | | | | | | 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. llvm-svn: 144165
* Misc fixes for clang driver on Mips Linux. Patch by Simon Atanasyan.Eli Friedman2011-11-082-0/+35
| | | | llvm-svn: 144108
* Add a default system include of '/include'. This isn't particularlyChandler Carruth2011-11-081-0/+5
| | | | | | | | | | | | 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. llvm-svn: 144089
* Whitespace.Chad Rosier2011-11-071-1/+1
| | | | llvm-svn: 144002
* Tablegenify -g options.Chad Rosier2011-11-071-15/+0
| | | | llvm-svn: 144001
* Fix an unsafe use of Twine.Benjamin Kramer2011-11-071-5/+4
| | | | llvm-svn: 143962
* Rip out one of the features I added for the driver-include-management.Chandler Carruth2011-11-071-8/+2
| | | | | | | | | | | | | | | | 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. llvm-svn: 143917
* Fix Linux libc++ usage. Somehow this slipped through during the port.Chandler Carruth2011-11-071-0/+8
| | | | | | | 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... llvm-svn: 143916
* Begin lifting some of the one-off checking logic into generic helperChandler Carruth2011-11-062-5/+18
| | | | | | routines on the base toolchain class. llvm-svn: 143900
* Move the GCC installation detection logic down into the Generic_GCCChandler Carruth2011-11-062-317/+318
| | | | | | | | | | 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. llvm-svn: 143899
* Remove an old OpenSUSE hack that is no longer needed -- it is exactlyChandler Carruth2011-11-061-5/+0
| | | | | | the same as a directory added further down in the new logic. llvm-svn: 143897
* Remove the HasMultilib check. It was essentially useless. The driver nowChandler Carruth2011-11-061-43/+25
| | | | | | | looks for evidence of a multilib installation, and adds the appropriate bits to the search paths. llvm-svn: 143896
* The version objects need to actually store the version strings; theyChandler Carruth2011-11-062-6/+6
| | | | | | aren't guaranteed to live long enough otherwise. llvm-svn: 143875
* Throw the switch and move all Linux header search over to the GCCChandler Carruth2011-11-061-334/+48
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 143874
* Add a missing triple spotted by inspecting and testing of the includeChandler Carruth2011-11-061-1/+2
| | | | | | path triples. Also order the 32-bit triples a bit more reasonably. llvm-svn: 143873
* Lift the GCCVersion type into the header file and start persisting it inChandler Carruth2011-11-062-84/+93
| | | | | | | the detected GCC installation. This allows us to expose another aspect of what we detected: the GCC version. This will be used shortly. llvm-svn: 143871
* Switch some of these interfaces from std::string to StringRef and Twine.Chandler Carruth2011-11-062-8/+7
| | | | | | This will facilitate further use and recombinations of them. llvm-svn: 143869
* Take a better approach to detecting and selecting multiarch includeChandler Carruth2011-11-061-14/+35
| | | | | | | | 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. llvm-svn: 143866
* Revert r143864, as the problem I was actually looking at can be solvedChandler Carruth2011-11-061-12/+0
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 143865
* Start pruning down the set of flags passed to CC1 for header search.Chandler Carruth2011-11-061-0/+12
| | | | | | | | | | | | | | 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. llvm-svn: 143864
* Fixing -g break caused by a dead reference to a temporary introduced in r143732.David Blaikie2011-11-061-1/+1
| | | | llvm-svn: 143856
* Add the depfile as a result file so that it is deleted if we crash,Peter Collingbourne2011-11-063-5/+13
| | | | | | and prevent the diagnostic preprocessor run from writing a depfile. llvm-svn: 143846
* Enhance the GCC version parsing and comparison logic to handle some moreChandler Carruth2011-11-051-18/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 143841
* Remove a pointless member. I have no idea why I made this not a localChandler Carruth2011-11-052-4/+2
| | | | | | | | 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. llvm-svn: 143840
* Remove a no-longer needed helper function. Thanks for implementing thisChandler Carruth2011-11-051-12/+4
| | | | | | Michael! llvm-svn: 143839
* Move the GCC installation detection helper a member of the LinuxChandler Carruth2011-11-052-236/+249
| | | | | | | | | | | | | | 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. llvm-svn: 143838
* Remove support for Gentoo subversion-ebuild installed llvm-gcc libstdc++Chandler Carruth2011-11-051-9/+0
| | | | | | | | | 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. llvm-svn: 143836
* Move the Linux header searching from the Frontend to the Driver. This isChandler Carruth2011-11-053-22/+464
| | | | | | | | | | | | | | | | 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. llvm-svn: 143822
* Try to reduce the nastiness that creeps in through Windows.h a bit.Benjamin Kramer2011-11-051-3/+3
| | | | llvm-svn: 143816
* [driver] If we're only linking, don't warn about unused arguments which areChad Rosier2011-11-051-2/+3
| | | | | | | obviously only used during compilation. rdar://10386708 llvm-svn: 143813
* 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
* On Linux, enable the gold plugin if we are using LTO.Peter Collingbourne2011-11-051-1/+1
| | | | llvm-svn: 143778
* Fix MSVC build.Michael J. Spencer2011-11-052-2/+12
| | | | llvm-svn: 143770
* Begin the migration of header search logic to the driver, starting withChandler Carruth2011-11-042-0/+275
| | | | | | | | | 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
* Switch the C++ include interface in the ToolChain to use the same namingChandler Carruth2011-11-041-3/+3
| | | | | | | as the system include interface before I start adding implementations of it to individual ToolChain implementations. llvm-svn: 143751
* Enable -flimit-debug-info by default. Now, clang lazily emits debug info for ↵Devang Patel2011-11-041-0/+1
| | | | | | structs. Original behavior can be restored using -fno-limit-debug-info. llvm-svn: 143733
* [driver] Don't blindly accept all -g options.Chad Rosier2011-11-041-2/+18
| | | | | | rdar://10383444 llvm-svn: 143732
* Sink the strange '-stdlib=...' flag handling into the C++ includeChandler Carruth2011-11-042-5/+11
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 143687
* Sink the handling of -fobjc-arc-cxxlib to live with the other -fobjc-arcChandler Carruth2011-11-042-20/+12
| | | | | | | | 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. llvm-svn: 143686
* Add a FIXME to cleanup the CPATH handling. It's currently burried withChandler Carruth2011-11-041-0/+2
| | | | | | | | the rest of the mess in InitHeaderSearch.cpp. We could hoist it into the driver profitably, removing more noise from the driver -> frontend communication. llvm-svn: 143685
* Add a system include management interface to the toolchain, and call itChandler Carruth2011-11-042-11/+19
| | | | | | | | | | | 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. llvm-svn: 143684
* In addition to dumping preprocessed source, dump a script with the command lineChad Rosier2011-11-021-2/+23
| | | | | | | arguments that caused clang to crash. rdar://8314451 llvm-svn: 143573
* Invoke the Darwin assembler with -g instead of --gdwarf2.Bob Wilson2011-11-021-1/+1
| | | | | | | | | 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> llvm-svn: 143533
* Add an option to emulate the strange Apple gcc behavior of #pragma pack.Eli Friedman2011-11-021-0/+4
| | | | | | <rdar://problem/10374763> llvm-svn: 143527
* 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
OpenPOWER on IntegriCloud