Windows uses PE/COFF which is inherently position independent. The use
of the PIC model is unnecessary. In fact, we would generate invalid
code using the ELF PIC model when PIC was enabled previously. Now that
we no longer accept -fPIC and -fpoc, this switches the internal
representation to the static model to permit us to make PIC modules
invalid when targeting Windows. This should not change the code
generation, only the internal state management.
llvm-svn: 290569
Summary:
The MSVC toolchain and Clang driver combination currently uses a fairly complex
sequence of steps to determine the MS compatibility version to pass to cc1.
There is some oddness in this sequence currently, with some code which inspects
flags in the toolchain, and some code which inspects the triple and local
environment in the driver code.
This change is an attempt to consolidate most of this logic so that
Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the
split, so any suggestions are welcome.
There are a few things you might want to watch for for specifically:
- On all platforms, if MSVC compatibility flags are provided (and valid), use
those.
- The fallback sequence should be the same as before, but is now consolidated
into MSVCToolChain::getMSVCVersion:
- Otherwise, try to use the Triple.
- Otherwise, on Windows, check the executable.
- Otherwise, on Windows or with --fms-extensions, default to 18.
- Otherwise, we can't determine the version.
- MSVCToolChain::ComputeEffectiveTriple no longer calls the base
ToolChain::ComputeEffectiveClangTriple. The only thing it would change for
Windows the architecture, which we don't care about for the compatibility
version.
- I'm not sure whether this is philosophically correct (but it should
be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not).
- Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look
like the effective triple was always being used previously anyhow.
Reviewers: hans, compnerd, llvm-commits, rnk
Subscribers: amccarth
Differential Revision: https://reviews.llvm.org/D27477
llvm-svn: 288998
Summary:
This patch includes support for argument translation that is specific of a given offloading kind. Additionally, it implements the translation for OpenMP device kinds in the gcc tool chain.
With this patch, it is possible to compile a functional OpenMP application with offloading capabilities with no separate compilation.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21848
llvm-svn: 285320
This fixes a couple of bugs in Windows SDK Detection.
1. `readFullStringValue` returns a bool, but was being compared
with ERROR_SUCCESS.
2. `RegQueryValueExW` might return the null terminator in the
queried value which will result in incorrect values being
returned from `getSystemRegistryString`.
Patch By: comicfans44@gmail.com
Reviewed By: zturner
Differential Revision: http://reviews.llvm.org/D21946
llvm-svn: 277005
No extra tests required as this is currently covered by existing testing, and this is basically impossible to write Unicode-specific tests for.
llvm-svn: 273563
Add support for /Ob1 (and equivalent -finline-hint-functions), which enable
inlining only for functions marked inline, either explicitly (via inline
keyword, for example), or implicitly (function definition in class body,
for example).
This works by enabling inlining pass, and adding noinline attribute to
every function not marked inline.
Patch by Rudy Pons <rudy.pons@ilod.org>!
Differential Revision: http://reviews.llvm.org/D20647
llvm-svn: 273440
-fms-compatibility-version was defaulting to 18 (VS 2013), which is a pain if your environment is pointing to version 19 (VS 2015) libraries.
If cl.exe can be found, this patch uses its version number as the default instead. It re-uses the existing code to find the Visual Studio binaries folder and WinAPI methods to check its version. You can still explicitly specify a compatibility version on the command line. If you don't have cl.exe, this should be a no-op and you'll get the old default of 18.
This affected the tests, which assumed that if you didn't specific a version, that it would default to 18, but this won't be true for all machines. So a couple test cases had to be eliminated and a couple others had to be tweaked to allow for various outputs.
Addresses: https://llvm.org/bugs/show_bug.cgi?id=27215
Differential Revision: http://reviews.llvm.org/D20136
llvm-svn: 269515
r217178 changed clang to add function attribute uwtable by default on
Win64, which caused the __eh_frame section to be emitted by default.
This commit restores the previous behavior for MachO targets.
rdar://problem/25282627
llvm-svn: 268589
r260990 exposed -isystem in clang-cl. -isystem adds a directory to the front of
the system include search path. The idea was to use this to point to a hermetic
msvc install, but as it turns out this doesn't work: -isystem then adds the
hermetic headers in front of clang's builtin headers, and clang's headers that
are supposed to wrap msvc headers (say, stdarg.h) aren't picked up at all
anymore.
So revert that, and instead expose -imsvc which works as if the passed
directory was part of %INCLUDE%: The header is treated as a system header, but
it is searched after clang's lib/Header headers.
Fixes half of PRPR26751.
llvm-svn: 266108
Microsoft's documentation states that specifying
/Oy- after the /O[12x] options disables frame-pointer omission.
What it does *not* state is that it also disables frame-pointer omission
if /Oy- is specified before /O[12x].
llvm-svn: 258447
Summary:
With Windows 10 SDK, Include and Lib directories now contain an additional subfolder with the name that corresponds to the full version of the SDK, for example:
- C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um
- C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\um\x64
Reviewers: ruiu, rnk
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D12832
llvm-svn: 248463
Summary:
With Visual Studio 2015 release, a part of runtime library was extracted
and now comes with Windows Kits. This patch enables clang to use
Universal CRT library if %INCLUDE or %LIB environment varaibles are not
specified.
See also https://llvm.org/bugs/show_bug.cgi?id=24741
Patch by Igor Kudrin
Reviewers: zturner, hans, rnk
Subscribers: ruiu, cfe-commits
Differential Revision: http://reviews.llvm.org/D12695
llvm-svn: 247362
We had multiple bugs here:
- We didn't support multiple optimization options in one argument.
e.g. -O2y-
- We didn't correctly expand -O[12dx] to their respective options.
- We treated -O1 as clang -O1 instead of clang -Os.
- We treated -Ox as clang -O3 instead of clang -O2. In fact, cl's -Ox
option is *less* powerful than cl's -O2 option despite -Ox described
as "Full Optimization".
This fixes PR24003.
llvm-svn: 243261
There are known issues, but the current implementation is good enough for
the check-cfi test suite.
Differential Revision: http://reviews.llvm.org/D11030
llvm-svn: 241728
Classes in Tools.h inherit ultimately from Tool, which is a noun,
but subclasses of Tool were named for their operation, such as "Compile",
wherein the constructor call "Compile(args...)" could be misconstrued
as actually causing a compile to happen.
Likewise various other methods were not harmonious with their effect,
in that "BuildLinker()" returned a "new namespace::Link(...)"
instead of a "new namespace::Linker(...)" which it now does.
Exceptions: Clang and ClangAs are un-renamed. Those are their rightful names.
And there is no particulary great way to name the "Lipo-er" and a few others.
Differential Revision: http://reviews.llvm.org/D10595
llvm-svn: 240455
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support and are
not toolchain- or architecture-dependent.
Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.
This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539).
Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.
This change was first submitted as r239953 and reverted in r239958.
The problem was and still is in Darwin toolchains, which get the
knowledge about target platform too late after initializaition, while
now we require this information when ToolChain::getSanitizerArgs() is
called. r240170 works around this issue.
llvm-svn: 240179
Summary:
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support (i.e.
set from -fsanitize=undefined-trap).
Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.
This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539)
Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.
Test Plan: regression test suite
Reviewers: pcc
Subscribers: cfe-commits, filcab, eugenis, thakis, kubabrecka, emaste, rsmith
Differential Revision: http://reviews.llvm.org/D10467
llvm-svn: 239953
The object file format is sometimes overridden for MSVC targets to use
ELF instead of COFF. Make sure we preserve this choice when setting the
msvc version number in the triple.
llvm-svn: 239388
Encoding the version into the triple will allow us to communicate to
LLVM what functions it can expect to depend upon in the implementation.
llvm-svn: 239273
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
Using lld on Windows requires calling link-lld.exe instead of
lld.exe. This patch puts this knowledge into clang so that when
using the GCC style clang driver, it can properly delegate to
lld.
Differential Revision: http://reviews.llvm.org/D6428
Reviewed by: Reid Kleckner, Rui Ueyama
llvm-svn: 223086
When a user has not configured a standard Visual Studio environment
by running vcvarsall, clang tries its best to find Visual Studio
include files and executables anyway. This patch makes clang also
try to find system and Windows SDK libraries for linking against,
as well.
Reviewed by: Hans Wennborg
Differential Revision: http://reviews.llvm.org/D5873
llvm-svn: 220425
This resubmits change r220226. That change broke the chromium
build bots because chromium it ships an hermetic MSVC toolchain
that it expects clang to fallback to by finding it on the path.
This patch fixes the issue by bumping up the prioritization of PATH
when looking for MSVC binaries.
Reviewed by: Hans Wennborg, Reid Kleckner
Differential Revision: http://reviews.llvm.org/D5892
llvm-svn: 220424
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
Reid Kleckner