summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/WindowsToolChain.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Driver: rename Windows to MSVCToolChainSaleem Abdulrasool2014-10-221-335/+0
| | | | | | | | This renames the Windows toolchain to MSVCToolChain. This is a preparatory step for adding a CrossWindowsToolChain which uses clang/libc++/(ld/lld) without the standard GCC toolchain lookup. NFC. llvm-svn: 220362
* Removing unused variable (assigned into, but never read from); NFC.Aaron Ballman2014-10-211-2/+0
| | | | llvm-svn: 220313
* Revert "Improve Windows toolchain support for non-standard environments." ↵Hans Wennborg2014-10-201-99/+90
| | | | | | | | | | | | | | (r220226) In environments where PATH was set to point to the VS installation, Clang would override that by looking in the registry and finding the latest VS installation. If the environment is set up to point to a VS installation, that should take precedence. Reverting this until we can fix it. llvm-svn: 220243
* Improve Windows toolchain support for non-standard environments.Zachary Turner2014-10-201-90/+99
| | | | | | | | | | | | | | | | | | | | | Typically clang finds Visual Studio by the user explicitly setting up a Visual Studio environment via vcvarsall. But we still try to behave intelligently and fallback to different methods of finding Visual Studio when this is not done. This patch improves various fallback codepaths to make Visual Studio locating more robust. Specifically, this patch: * Adds support for searching environment variables for VS 12.0 * Correctly locates include folders for Windows SDK 8.x (this was previously broken, and would cause clang to error) * Prefers locating link.exe in the same location as cl.exe. This is helpful in case another link.exe is in the path earlier than Visual Studio (e.g. GnuWin32) * Minor cleanup in the registry reading code to make it more robust in the presence of long pathnames. llvm-svn: 220226
* Win64: Add the uwtable attribute by default on Win64Reid Kleckner2014-09-041-5/+4
| | | | | | | Now that LLVM emits correct .pdata and .xdata for inline functions, we can reenable this. llvm-svn: 217178
* Win64: Disable uwtable until we fix .pdata emission in LLVMReid Kleckner2014-07-011-1/+5
| | | | | | | | | LLVM r211399 started emitting .pdata for win64 by default. Unfortunately, it produces invalid object files. I plan to fix that Soon. For now, don't request unwind tables. This fixes the clang-cl self-host on win64. llvm-svn: 212137
* Use lowercase windows.h for mingw cross compilation.Logan Chien2014-06-241-1/+1
| | | | llvm-svn: 211604
* Enable WindowsToolChain on all native Windows buildsAlp Toker2014-06-221-7/+2
| | | | | | | | Make binaries built by MSVC, mingw and clang functionally equivalent. The checks are trivially performed at runtime to eliminate functional differences between supported configurations that used to be hard-coded. llvm-svn: 211461
* WindowsToolChain: decouple build environment from the toolchainAlp Toker2014-06-221-17/+2
| | | | | | | | | | | Don't try to find the MSVC version that the binaries were built with. Doing so defeats testing by causing invalid test passes on the build servers. Whichever Visual Studio (or clang-cl.exe) edition was used to build the clang package, it's strictly orthogonal and has no relation to software versions available on the user's PC. llvm-svn: 211459
* Make WindowsToolChain portableAlp Toker2014-06-221-10/+19
| | | | | | | | De-conditionalize as much as possible so we can start to fix this code. No change in functionality. llvm-svn: 211458
* [C++11] Use 'nullptr'. Driver edition.Craig Topper2014-05-171-1/+1
| | | | llvm-svn: 209069
* Revert "Reland r206934 with a hopefully fixed test"Rafael Espindola2014-04-251-1/+1
| | | | | | | This reverts commit r207155. The test was still failing. llvm-svn: 207225
* Reland r206934 with a hopefully fixed testReid Kleckner2014-04-241-1/+1
| | | | llvm-svn: 207155
* This reverts commit r206934 and r206935.Rafael Espindola2014-04-231-1/+1
| | | | | | | | | | The original messages were: "Driver: Honor %INCLUDE% when built with MinGW" "Add missing test triples" The test was still failing on OS X. llvm-svn: 206973
* Driver: Honor %INCLUDE% when built with MinGWReid Kleckner2014-04-231-1/+1
| | | | | | | | | | | Users are expected to pass system includes through the INCLUDE environment variable on Windows. There's no reason to change behavior based on the toolchain used to build Clang. I didn't change the registry searching code because I'm not sure it builds with mingw and I'm not set up to test it. llvm-svn: 206934
* Driver: Avoid a duplicate path separator and clean up codeReid Kleckner2014-04-231-17/+19
| | | | llvm-svn: 206933
* 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
OpenPOWER on IntegriCloud