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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Reid Kleckner