summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
* Remove the unuseful -fdiagnostics-show-nameDavid Blaikie2012-02-151-5/+0
| | | | | | | | | | | | | | This option was added in r129614 and doesn't have any use case that I'm aware of. It's possible that external tools are using these names - and if that's the case we can certainly reassess the functionality, but for now it lets us shave out a few unneeded bits from clang. Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool. This removes the actual diagnostic name strings from clang entirely. Reviewed by Chris Lattner & Ted Kremenek. llvm-svn: 150612
* Add some Solaris include paths and fix a -lgcc_eh that apparently should be ↵David Chisnall2012-02-151-1/+1
| | | | | | -lgcc_s. llvm-svn: 150602
* Fix copy-and-paste error in commentDavid Chisnall2012-02-151-1/+1
| | | | llvm-svn: 150587
* First pass at Solaris toolchain support. This version compiles and links helloDavid Chisnall2012-02-155-0/+198
| | | | | | | | world on Solaris 11 for both x86 and x86-64 using the built-in assembler and Solaris (not GNU) ld, however it currently relies on a hard-coded GCC location to find crtbegin.o and crtend.o, as well as libgcc and libgcc_eh. llvm-svn: 150580
* include clang's config.h unconditionally (v2)Dylan Noblesmith2012-02-142-10/+3
| | | | | | | | | | And remove HAVE_CLANG_CONFIG_H, now that the header is generated in the autoconf build, too. Reverts r149571/restores r149504, now that config.h is generated correctly by LLVM's configure in all build configurations. llvm-svn: 150487
* When generating diagnostic information due to a clang failure, allow multipleChad Rosier2012-02-131-9/+10
| | | | | | | | | -arch options if the're all the same. Patch by Jeremy Huddleston. rdar://10849701 llvm-svn: 150403
* Delete a simplistic helper function now that llvm::Triple can provideChandler Carruth2012-02-131-13/+3
| | | | | | this functionality. llvm-svn: 150358
* Begin refactoring to use the newly added triple predicates forChandler Carruth2012-02-112-12/+4
| | | | | | | simplicity. Also addresses a FIXME, although not one that could be observed. llvm-svn: 150294
* Have the driver pass CPU and target feature information to cc1as.Jim Grosbach2012-02-102-0/+62
| | | | | | | | | | When creating the MCSubtargetInfo, the assembler driver uses the CPU and feature string to construct a more accurate model of what instructions are and are not legal. rdar://10840476 llvm-svn: 150273
* Correct comment Clang C++ use in production.David Blaikie2012-02-091-1/+1
| | | | | | | | | | This was from way-back-when (r82583) when Clang's C++ support wasn't prime-time yet. Production quality C++ was tested experimentally from r100119 and turned on by default in r141063. Patch by Justin Bogner. llvm-svn: 150148
* Filter a few more options not recognized by gcc. <rdar://problem/10814020>Bob Wilson2012-02-071-3/+17
| | | | | | | These are new options that gcc doesn't recognize so the clang driver needs to remove them when it falls back to invoking gcc. llvm-svn: 149951
* Rewrite the debug action handling to take -verify into account.Eric Christopher2012-02-062-18/+17
| | | | | | | Add a quiet option for dwarfdump and move it out of NDEBUG only. Still requires an option as we don't want this on by default. llvm-svn: 149894
* Update the command line here and update the comment, we're just goingEric Christopher2012-02-062-3/+4
| | | | | | to leave this as a debug only option for now. llvm-svn: 149890
* - Turn the other distribution checks into range compares.Benjamin Kramer2012-02-061-18/+14
| | | | | | | - Turn openSUSE version parsing into a StringSwitch - Add an entry for Fedora release 16 (Verne) llvm-svn: 149872
* Consolidate the ubuntu detection logic a bit, add an entry for Ubuntu 12.04 ↵Benjamin Kramer2012-02-061-28/+20
| | | | | | aka precise pangolin. llvm-svn: 149869
* Basic: import SmallString<> into clang namespaceDylan Noblesmith2012-02-055-15/+15
| | | | | | | (I was going to fix the TODO about DenseMap too, but that would break self-host right now. See PR11922.) llvm-svn: 149799
* Basic: import OwningPtr<> into clang namespaceDylan Noblesmith2012-02-052-2/+2
| | | | llvm-svn: 149798
* Fix -ftrap-function fallout from llvm r145714. <rdar://problem/10799325>Bob Wilson2012-02-031-6/+1
| | | | | | | | | That llvm change removed the -trap-func backend option, so that using -ftrap-function with clang would cause the backend to complain. Fix it by adding the trap function name to the CodeGenOptions and passing it through to the TargetOptions. llvm-svn: 149679
* Replace the old --with-cxx-* configure options with a single ↵Rafael Espindola2012-02-031-48/+13
| | | | | | | | | --with-gcc-toolchain that just uses the new toolchain probing logic. This fixes linking with -m32 on 64 bit systems (the /32 dir was not being added to the search). llvm-svn: 149652
* back out r149504Dylan Noblesmith2012-02-022-3/+10
| | | | | | Too many weird build failures. llvm-svn: 149571
* include clang's config.h unconditionallyDylan Noblesmith2012-02-013-14/+3
| | | | | | | | | | | | | And remove HAVE_CLANG_CONFIG_H, now that the header is generated in the autoconf build, too. (clang r149497 / llvm r149498) Also include the config.h header after all other headers, per the LLVM coding standards. It also turns out WindowsToolChain.cpp wasn't using the config header at all, so that include's just deleted now. llvm-svn: 149504
* Use new Triple::getMacOSXVersion function.Bob Wilson2012-01-311-31/+6
| | | | llvm-svn: 149439
* Fix more fallout from the introduction of "macosx" and "ios" triples.Bob Wilson2012-01-311-10/+37
| | | | | | | | | | | | The Darwin toolchain constructor was assuming that all Darwin triples would have an OS string starting with "darwin". Triples starting with "macosx" would misinterpret the version number, and "ios" triples would completely miss the version number (or worse) because the OS name is not 6 characters long. We lose some sanity checking of triple strings here, since the Triple.getOSVersion function doesn't do all the checking that the previous code did, but this still seems like a step in the right direction. llvm-svn: 149422
* Revert r149083 which is not the direction we're going in the ClangChandler Carruth2012-01-315-98/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | driver based on discussions with Doug Gregor. There are several issues: 1) The patch was not reviewed prior to commit and there were review comments. 2) The design of the functionality (triple-prefixed tool invocation) isn't the design we want for Clang going forward: it focuses on the "user triple" rather than on the "toolchain triple", and forces that bit of state into the API of every single toolchain instead of handling it automatically in the common base classes. 3) The tests provided are not stable. They fail on a few Linux variants (Gentoo among them) and on mingw32 and some other environments. I *am* interested in the Clang driver being able to invoke triple-prefixed tools, but we need to design that feature the right way. This patch just extends the previous hack without fixing the underlying problems with it. I'm working on a new design for this that I will mail for review by tomorrow. I am aware that this removes functionality that NetBSD relies on, but this is ToT, not a release. This functionality hasn't been properly designed, implemented, and tested yet. We can't "regress" until we get something that really works, both with the immediate use cases and with long term maintenance of the Clang driver. For reference, the original commit log: Keep track of the original target the user specified before normalization. This used to be captured in DefaultTargetTriple and is used for the (optional) $triple-$tool lookup for cross-compilation. Do this properly by making it an attribute of the toolchain and use it in combination with the computed triple as index for the toolchain lookup. llvm-svn: 149337
* [analyzer] Rename the checker as per Ted's comment. Remove the referenceAnna Zaks2012-01-301-1/+0
| | | | | | from the driver. llvm-svn: 149276
* Remove the ToolTriple logic in NetBSD, which was completely broken byJoerg Sonnenberger2012-01-263-14/+8
| | | | | | | | the recent refactoring. All interesting NetBSD release have a GNU as version on i386 that supports --32, so don't bother with the conditional setting of it. llvm-svn: 149087
* Remove obviously incorrect branch.Joerg Sonnenberger2012-01-261-2/+1
| | | | llvm-svn: 149084
* Keep track of the original target the user specified beforeJoerg Sonnenberger2012-01-265-67/+98
| | | | | | | | | | normalization. This used to be captured in DefaultTargetTriple and is used for the (optional) $triple-$tool lookup for cross-compilation. Do this properly by making it an attribute of the toolchain and use it in combination with the computed triple as index for the toolchain lookup. llvm-svn: 149083
* Revert r148249: "Make the auto-detection hack for the iOS simulator set the ↵Bob Wilson2012-01-261-25/+22
| | | | | | | | target triple correctly." There were some problems with this, so I'm backing it out for now. llvm-svn: 149040
* Enable several checkers under --analyze for general testing.Ted Kremenek2012-01-261-0/+9
| | | | llvm-svn: 149016
* Reintroduce r148981 with significantly improved regression test. Now itChandler Carruth2012-01-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | both actually tests what it wants to, doesn't have bogus and broken assertions in it, and is also formatted much more cleanly and consistently. Probably still some more that can be improved here, but its much better. Original commit message: ---- Try to unbreak the FreeBSD toolchain's detection of 32-bit targets inside a 64-bit freebsd machine with the 32-bit compatibility layer installed. The FreeBSD image always has the /usr/lib32 directory, so test for the more concrete existence of crt1.o. Also enhance the tests for freebsd to clarify what these trees look like and exercise the new code. Thanks to all the FreeBSD folks for helping me understand what caused the failure and how we might fix it. =] That helps a lot. Also, yay build bots. llvm-svn: 149011
* Revert r148981 because it fails test/Driver/freebsd.cArgyrios Kyrtzidis2012-01-251-3/+3
| | | | | | | | | | | | | | | | | | | | Original log: Author: chandlerc <chandlerc@91177308-0d34-0410-b5e6-96231b3b80d8> Date: Wed Jan 25 21:32:31 2012 +0000 Try to unbreak the FreeBSD toolchain's detection of 32-bit targets inside a 64-bit freebsd machine with the 32-bit compatibility layer installed. The FreeBSD image always has the /usr/lib32 directory, so test for the more concrete existence of crt1.o. Also enhance the tests for freebsd to clarify what these trees look like and exercise the new code. Thanks to all the FreeBSD folks for helping me understand what caused the failure and how we might fix it. =] That helps a lot. Also, yay build bots. llvm-svn: 148993
* Try to unbreak the FreeBSD toolchain's detection of 32-bit targetsChandler Carruth2012-01-251-3/+3
| | | | | | | | | | | | | | inside a 64-bit freebsd machine with the 32-bit compatibility layer installed. The FreeBSD image always has the /usr/lib32 directory, so test for the more concrete existence of crt1.o. Also enhance the tests for freebsd to clarify what these trees look like and exercise the new code. Thanks to all the FreeBSD folks for helping me understand what caused the failure and how we might fix it. =] That helps a lot. Also, yay build bots. llvm-svn: 148981
* Restore a tiny bit of functionality that I completely overlooked in theChandler Carruth2012-01-251-1/+4
| | | | | | | | | | Linux toolchain selection -- sorry folks. =] This should fix the Hexagon toolchain. However, I would point out that I see why my testing didn't catch this -- we have no tests for Hexagon. ;] llvm-svn: 148977
* The Linux pattern of adding all the search paths that exist doesn't seemChandler Carruth2012-01-251-12/+12
| | | | | | | | | | | to suit the FreeBSD folks. Take them back to something closer to the old behavior. We test whether the /usr/lib32 directory exists (within the SysRoot), and use it if so, otherwise use /usr/lib. FreeBSD folks, let me know if this causes any problems, or if you have further tweaks. llvm-svn: 148953
* Remove the 'ToolTriple' concept from the NetBSD toolchain along with myChandler Carruth2012-01-253-19/+15
| | | | | | | | | | | | | | | | gross hack to provide it from my previous patch removing HostInfo. This was enshrining (and hiding from my searches) the concept of storing and diff-ing the host and target triples. We don't have the host triple reliably available, so we need to merely inspect the target system. I've changed the logic in selecting library search paths for NetBSD to match what I provided for FreeBSD -- we include both search paths, but put the 32-bit-on-64-bit-host path first so it trumps. NetBSD maintainers, you may want to tweak this, or feel free to ask me to tweak it. I've left a FIXME here about the challeng I see in fixing this properly. llvm-svn: 148952
* Delete still more remnants of the now dead HostInfo. The janitoring willChandler Carruth2012-01-251-1/+0
| | | | | | continue until cleanliness improves. llvm-svn: 148951
* Delete the driver's HostInfo class. This abstraction just never reallyChandler Carruth2012-01-254-725/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | did anything. The two big pieces of functionality it tried to provide was to cache the ToolChain objects for each target, and to figure out the exact target based on the flag set coming in to an invocation. However, it had a lot of flaws even with those goals: - Neither of these have anything to do with the host, or its info. - The HostInfo class was setup as a full blown class *hierarchy* with a separate implementation for each "host" OS. This required dispatching just to create the objects in the first place. - The hierarchy claimed to represent the host, when in fact it was based on the target OS. - Each leaf in the hierarchy was responsible for implementing the flag processing and caching, resulting in a *lot* of copy-paste code and quite a few bugs. - The caching was consistently done based on architecture alone, even though *any* aspect of the targeted triple might change the behavior of the configured toolchain. - Flag processing was already being done in the Driver proper, separating the flag handling even more than it already is. Instead of this, we can simply have the dispatch logic in the Driver which previously created a HostInfo object create the ToolChain objects. Adding caching in the Driver layer is a tiny amount of code. Finally, pulling the flag processing into the Driver puts it where it belongs and consolidates it in one location. The result is that two functions, and maybe 100 lines of new code replace over 10 classes and 800 lines of code. Woot. This also paves the way to introduce more detailed ToolChain objects for various OSes without threading through a new HostInfo type as well, and the accompanying boiler plate. That, of course, was the yak I started to shave that began this entire refactoring escapade. Wheee! llvm-svn: 148950
* Switch the ToolChain types to all store a Driver reference rather thanChandler Carruth2012-01-255-64/+61
| | | | | | | | | | a HostInfo reference. Nothing about the HostInfo was used by any toolchain except digging out the driver from it. This just makes that a lot more direct. The change was accomplished entirely mechanically. It's one step closer to removing the shim full of buggy copy/paste code that is HostInfo. llvm-svn: 148945
* Remove the TargetTriple object that I added to the Driver recently. ThisChandler Carruth2012-01-251-12/+12
| | | | | | | | | | | | | | | helped stage the refactoring of things a bit, but really isn't the right place for it. The driver may be responsible for compilations with many different targets. In those cases, having a target triple in the driver is actively misleading because for many of those compilations that is not actually the triple being targeted. This moves the last remaining users of the Driver's target triple to instead use the ToolChain's target triple. The toolchain has a single, concrete target it operates over, making this a more stable and natural home for it. llvm-svn: 148942
* Have FreeBSD use even more of the same smarts as Linux is now using forChandler Carruth2012-01-251-6/+6
| | | | | | | | | | | | | | | adding search paths. Add them only when they exist, and prefix the paths with the sysroot. This will allow targeting a FreeBSD sysroot on a non-FreeBSD host machine, and perhaps more importantly should allow testing the FreeBSD driver's behavior similarly to the Linux tests with a fake tree of files in the regression test suite. I don't have FreeBSD systems handy to build up the list of files that should be used here, but this is the basic functionality and I'm hoping Roman or someone from the community can contribute the actual test cases. llvm-svn: 148940
* Switch FreeBSD to just include both '/usr/lib32' and '/usr/lib' in theChandler Carruth2012-01-251-16/+7
| | | | | | | | | search paths for 32-bit targets. This avoids having to detect which is expected for the target system, and the linker should DTRT, and take the 32-bit libraries from the first one when applicable. Thanks to Roman Divacky for sanity checking this. llvm-svn: 148939
* Switch the Linux C++ standard library header search logic over to useChandler Carruth2012-01-251-15/+8
| | | | | | the GCC installation's multiarch suffix now that it is exposed. llvm-svn: 148938
* Make a major refactoring to how the GCC installation detection works.Chandler Carruth2012-01-252-132/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fundamental shift here is to stop making *any* assumptions about the *host* triple. Where these assumptions you ask? Why, they were in one of the two target triples referenced of course. This was the single biggest place where the previously named "host triple" was actually used as such. ;] The reason we were reasoning about the host is in order to detect the use of '-m32' or '-m64' flags to change the target. These flags shift the default target only slightly, which typically means a slight deviation from the host. When using these flags, the GCC installation is under a different triple from the one actually targeted in the compilation, and we used the host triple to find it. Too bad that wasn't even correct. Consider an x86 Linux host which has a PPC64 cross-compiling GCC toolchain installed. This toolchain is also configured for multiarch compiling and can target PPC32 with eth '-m32' flag. When targeting 'powerpc-linux-gnu' or some other PPC32 triple, we have to look for the PPC64 variant of the triple to find the GCC install, and that triple is neither the host nor target. The new logic computes the multiarch's alternate triple from the target triple, and looks under both sides. It also looks more aggressively for the correct subdirectory of the GCC installation, and exposes the subdirectory in a nice programmatic way. This '/32' or '/64' suffix is something we can reuse in many other parts of the toolchain. An important note -- while this likely fixes a large category of cross-compile use cases, that's not my primary goal, and I've not done testing (or added test cases) for scenarios that may now work. If someone else wants to try more interesting PPC cross compiles, I'd love to have reports. But my focus is on factoring away the references to the "host" triple. The refactoring is my goal, and so I'm mostly relying on the existing (pretty good) test coverage we have here. Future patches will leverage this new functionality to factor out more and more of the toolchain's triple manipulation. llvm-svn: 148935
* Fix one of the (larger) FIXMEs where we were misusing the Driver's ideaChandler Carruth2012-01-241-19/+23
| | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 148852
* Address one part of the FIXME I introduced my switching the tripleChandler Carruth2012-01-242-15/+14
| | | | | | | | | | 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. llvm-svn: 148843
* At least within these classes, consistently spell 'GCC' as 'GCC'.Chandler Carruth2012-01-242-24/+24
| | | | | | | | I can't read Java-style 'Gcc' acronyms. ;] No functionality changed. llvm-svn: 148840
* Start hoisting the logic for computing the target triple into its ownChandler Carruth2012-01-242-18/+28
| | | | | | | | | | | | | | | | | | | | | | 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... llvm-svn: 148839
* Remove HostInfo::useDriverDriver(). This was only used in two placesChandler Carruth2012-01-242-70/+6
| | | | | | | | | | | | inside the innards of the Driver implementation, and only ever implemented to return 'true' for the Darwin OSes. Instead use a more direct query on the target triple and a comment to document why the target matters here. If anyone is worried about this predicate getting wider use or improper use, I can make it a local or private predicate in the driver. llvm-svn: 148797
* Hoist the targeted triple object into an actual object in the Driver.Chandler Carruth2012-01-241-3/+7
| | | | | | | | | The Driver has a fixed target, whether we like it or not, the DefaultTargetTriple is not a default. This at least makes things more honest. I'll eventually get rid of most (if not all) of DefaultTargetTriple with this proper triple object. Bit of a WIP. llvm-svn: 148796
OpenPOWER on IntegriCloud