summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/WindowsToolChain.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Use the new Windows environment for target detectionSaleem Abdulrasool2014-03-271-1/+1
| | | | | | | | | This follows the LLVM change to canonicalise the Windows target triple spellings. Rather than treating each Windows environment as a single entity, the environments are now modelled properly as an environment. This is a mechanical change to convert the triple use to reflect that change. llvm-svn: 204978
* Update for LLVM API changeSaleem Abdulrasool2014-03-061-1/+1
| | | | | | | Use the new getObjectFormat/setObjectFormat instead of Environment now that the file format is a separate field. llvm-svn: 203161
* Driver: Don't use DOS style paths on UNIXDavid Majnemer2014-01-311-1/+1
| | | | | | | We'd add, as a fallback, DOS style paths when using the driver using a win32 triple. On a UNIX-like platform, this isn't particularly helpful. llvm-svn: 200507
* Tidy up the no-external-assembler diagAlp Toker2013-11-221-1/+1
| | | | | | | | Diags aren't usually in the first person, and 'windows' isn't the correct product spelling to use in prose. Sidestep issues completely by making this error message platform-neutral. llvm-svn: 195422
* Locate VS InstallDir in the presence of newer runtimeHans Wennborg2013-10-101-20/+19
| | | | | | | | | | | This fixes getSystemRegistryString() in WindowsToolChain.cpp to make sure that the VS version that it picks has an InstallDir. Previously we would look for the highest version os VS and check for InstallDir afterwards. Patch by Yaron Keren! llvm-svn: 192374
* Use KEY_WOW64_32KEY when reading the registry in WindowsToolChain.cpp (PR17033)Hans Wennborg2013-10-091-3/+6
| | | | | | | | This exposes a 32-bit view of the registry even when Clang is built as a 64-bit program. Since Visual Studio is a 32-bit application, this is necessary for us to find it. llvm-svn: 192331
* Revert r188531: "Windows ToolChain: add VS bin dir to PogramPaths"Hans Wennborg2013-08-301-42/+37
| | | | | | | | | | | | | | | | | | | | | This never really worked. Even if we find and execute link.exe in the VS bin dir this way, link.exe wouldn't find the DLLs it needs, libraries, etc. It also causes trouble when the user has multiple versions of VS installed, one of them is in the path, but this code finds the other one (PR17041). Revert until we can fix this properly. > Windows ToolChain: add VS bin dir to PogramPaths > > We have a lot of fancy logic to find Visual Studio, which is currently used > to set the system header include paths. > > Use the same code to set the ProgramPaths, which is used for finding programs > such as link.exe. Previously, Clang would just search PATH for link.exe, > but now it should find it if it's able to find Visual Studio. llvm-svn: 189661
* Windows ToolChain: add VS bin dir to PogramPathsHans Wennborg2013-08-161-37/+42
| | | | | | | | | | | | | We have a lot of fancy logic to find Visual Studio, which is currently used to set the system header include paths. Use the same code to set the ProgramPaths, which is used for finding programs such as link.exe. Previously, Clang would just search PATH for link.exe, but now it should find it if it's able to find Visual Studio. Differential Revision: http://llvm-reviews.chandlerc.com/D1417 llvm-svn: 188531
* Remove PathV1.h use from WindowsToolChain.cpp.Rafael Espindola2013-06-261-3/+2
| | | | llvm-svn: 184906
* Include PathV1.h only where it is used.Rafael Espindola2013-06-171-0/+1
| | | | llvm-svn: 184090
* [Driver] Refactor clang driver to use LLVM's Option libraryReid Kleckner2013-06-141-2/+3
| | | | | | | | | | | | | | | | | | The big changes are: - Deleting Driver/(Arg|Opt)* - Rewriting includes to llvm/Option/ and re-sorting - 'using namespace llvm::opt' in clang::driver - Fixing the autoconf build by adding option everywhere As discussed in the review, this change includes using directives in header files. I'll make follow up changes to remove those in favor of name specifiers. Reviewers: espindola Differential Revision: http://llvm-reviews.chandlerc.com/D975 llvm-svn: 183989
* If the user requested a zero-base-shadow sanitizer, infer -pie and -fPIC ↵Peter Collingbourne2013-04-091-0/+4
| | | | | | | | when appropriate. Differential Revision: http://llvm-reviews.chandlerc.com/D502 llvm-svn: 179082
* Reject -no-integrated-as on windows.Rafael Espindola2013-03-241-4/+3
| | | | llvm-svn: 177840
* Remove the Tools DensMap from the toolchain.Rafael Espindola2013-03-201-11/+9
| | | | | | | | | | Each toolchain has a set of tools, but they are all of known types. It can have a linker, an assembler, a "clang" (compile, analyze, ...) a non-clang compiler, etc. Instead of keeping a map, just have member variable for each type of tool. llvm-svn: 177479
* Go back to using the integrated assembler on windows ever when passedRafael Espindola2013-03-191-2/+3
| | | | | | -no-integrated-as. It is the only assembler we have there. llvm-svn: 177398
* Finish refactoring the tool selection logic.Rafael Espindola2013-03-191-11/+2
| | | | | | | | | The general pattern now is that Foobar::constructTool only creates tools defined in the tools::foobar namespace and then delegates to the parent. The remaining duplicated code is now in the tools themselves. llvm-svn: 177368
* Centralize the logic for using the integrated assembler.Rafael Espindola2013-03-181-4/+2
| | | | llvm-svn: 177360
* Centralize the recording of which tools have been constructed.Rafael Espindola2013-03-181-18/+6
| | | | llvm-svn: 177319
* Use early returns when checking if we already constructed a tool and whenRafael Espindola2013-03-181-23/+24
| | | | | | delegating to Generic_GCC::SelectTool (it already updates the tool map). llvm-svn: 177305
* Remove unused argument.Rafael Espindola2013-03-181-1/+1
| | | | llvm-svn: 177303
* Pass an ArgList to every toolchain constructor. Remove the useIntegratedAsRafael Espindola2013-03-181-3/+4
| | | | | | argument. llvm-svn: 177301
* Refactor a bit of duplicated code to useIntegratedAs.Rafael Espindola2013-03-181-5/+2
| | | | llvm-svn: 177299
* Remove unused argument.Rafael Espindola2013-03-181-2/+1
| | | | llvm-svn: 177293
* Remove unused argument.Rafael Espindola2013-03-181-1/+1
| | | | llvm-svn: 177287
* Remove the SplitDebug action and replace with a set of commandsEric Christopher2013-02-211-2/+0
| | | | | | | in the compilation setup. Note that this doesn't currently work for -no-integrated-as. llvm-svn: 175813
* Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h.Jordan Rose2013-02-081-2/+3
| | | | | | | Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
* Driver and option support for -gsplit-dwarf. This is a part ofEric Christopher2013-02-051-0/+1
| | | | | | the DWARF5 split dwarf proposal. llvm-svn: 174349
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-2/+1
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Completely re-work how the Clang driver interprets PIC and PIE options.Chandler Carruth2012-11-191-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
* Revert r167567, restoring the ability of clang to run gcc in cases where itNick Lewycky2012-11-151-1/+6
| | | | | | can't handle the input file type. This resulted in PR14338. llvm-svn: 168024
* Rip out a bunch of code for invoking gcc from clang.Bob Wilson2012-11-081-6/+1
| | | | llvm-svn: 167567
* Use getArch instead of getArchName + string compare.Rafael Espindola2012-10-071-1/+1
| | | | llvm-svn: 165370
* Use getArch instead of getArchName.Rafael Espindola2012-10-071-3/+1
| | | | | | | | | | | | The darwin change should be a nop since Triple::getArchTypeForDarwinArchName doesn't know about amd64. If things like amd64-mingw32 are to be rejected, we should print a error earlier on instead of silently using the wrong abi. Remove old comment that looks out of place, this is "in clang". llvm-svn: 165368
* Revert r163076 per chandlerc's request.Joao Matos2012-09-041-34/+22
| | | | llvm-svn: 163146
* Fixed typo causing tests to fail on non-MSVC machines.Joao Matos2012-09-011-1/+1
| | | | llvm-svn: 163077
* Refactored the Windows headers location lookup code. Expose it so standalone ↵Joao Matos2012-09-011-22/+34
| | | | | | tools can have access to it. llvm-svn: 163076
* [msvc] Honor %INCLUDE%. It should know essential search paths with ↵NAKAMURA Takumi2012-03-131-1/+17
| | | | | | | | | | | | | | | | | | | | | vcvarsall.bat. FYI, On VS10, %INCLUDE% contains; (VS10)\VC\INCLUDE (VS10)\VC\ATLMFC\INCLUDE (SDK70A)\include On VS11, (VS11)\VC\INCLUDE (VS11)\VC\ATLMFC\INCLUDE (SDK80)\include\shared (SDK80)\include\um (SDK80)\include\winrt FIXME: It may be enabled also on mingw. llvm-svn: 152589
* Add new code migrator support for migrating existing Objective-C code to useTed Kremenek2012-03-061-0/+1
| | | | | | | | | | | the new Objective-C NSArray/NSDictionary/NSNumber literal syntax. This introduces a new library, libEdit, which provides a new way to support migration of code that improves on the original ARC migrator. We now believe that most of its functionality can be refactored into the existing libraries, and thus this new library may shortly disappear. llvm-svn: 152141
* include clang's config.h unconditionallyDylan Noblesmith2012-02-011-4/+0
| | | | | | | | | | | | | 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
* Revert r149083 which is not the direction we're going in the ClangChandler Carruth2012-01-311-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Keep track of the original target the user specified beforeJoerg Sonnenberger2012-01-261-2/+3
| | | | | | | | | | 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
* Switch the ToolChain types to all store a Driver reference rather thanChandler Carruth2012-01-251-3/+2
| | | | | | | | | | 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
* Split the Windows toolchain definition into its own file. This isChandler Carruth2011-12-171-0/+356
especially nice as the Windows toolchain needs the windows header files, and has lots of platform specific hooks in it. To facilitate the split, hoist a bunch of file-level static helpers into class-level static helpers. Spiff up their doxygen comments while there as they're now more likely to be looked up via docs. Hopefully, this will be followed by further breaking apart of the toolchain definitions. Most of the large and complex ones should likely live on their own. I'm looking at you Darwin. ;] llvm-svn: 146840
OpenPOWER on IntegriCloud