The test was missing '--' on mac as pointed out by -Wslash-u-filename:
<stdin>:5:69: note: possible intended match here
clang: warning: '/Users/thakis/src/llvm-mono/clang/test/Driver/msvc-link.c' treated as the '/U' option [-Wslash-u-filename]
Differential Revision: https://reviews.llvm.org/D51635
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@341654 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@341082 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@340949 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@340860 91177308-0d34-0410-b5e6-96231b3b80d8
Wmsvc-not-found was added in r297851 to help diagnose why link.exe can't be
executed. However, it's emitted even when using -fuse-ld=lld, and in cross
builds there's no way to get rid of the warning other than disabling it.
Instead, emit it when we look up link.exe and it ends up not being executable.
That way, when passing -fuse-ld=lld it will never be printed.
It will also not be printed if we find link.exe on PATH.
(We might want to eventually default to lld one day, at least when running on a
non-Win host, but that's for another day.)
Fixes PR38016.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@337290 91177308-0d34-0410-b5e6-96231b3b80d8
Similarly to CFI on virtual and indirect calls, this implementation
tries to use program type information to make the checks as precise
as possible. The basic way that it works is as follows, where `C`
is the name of the class being defined or the target of a call and
the function type is assumed to be `void()`.
For virtual calls:
- Attach type metadata to the addresses of function pointers in vtables
(not the functions themselves) of type `void (B::*)()` for each `B`
that is a recursive dynamic base class of `C`, including `C` itself.
This type metadata has an annotation that the type is for virtual
calls (to distinguish it from the non-virtual case).
- At the call site, check that the computed address of the function
pointer in the vtable has type `void (C::*)()`.
For non-virtual calls:
- Attach type metadata to each non-virtual member function whose address
can be taken with a member function pointer. The type of a function
in class `C` of type `void()` is each of the types `void (B::*)()`
where `B` is a most-base class of `C`. A most-base class of `C`
is defined as a recursive base class of `C`, including `C` itself,
that does not have any bases.
- At the call site, check that the function pointer has one of the types
`void (B::*)()` where `B` is a most-base class of `C`.
Differential Revision: https://reviews.llvm.org/D47567
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335569 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331834 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331069 91177308-0d34-0410-b5e6-96231b3b80d8
Starting with the Fall Creators Update, Windows 10 Desktop can run on
machines that are powered by aarch64 processors.
Microsoft call the aarch64 architecture "arm64". This patch maps
ArchType::aarch64 to "arm64" to allow the MSVC toolchain driver to find
the aarch64 / arm64 cross-compiler.
Patch by Chris January
Differential Revision: https://reviews.llvm.org/D44087
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@326744 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315536 91177308-0d34-0410-b5e6-96231b3b80d8
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315530 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This raises our default past 1900, which controls whether char16_t is a
builtin type or not.
Implements PR34243
Reviewers: hans
Subscribers: STL_MSFT, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D38646
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315107 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
* Rename -shared-libasan to -shared-libsan, keeping the old name as alias.
* Add -static-libsan for targets that default to shared.
* Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there.
* Support libclang_rt.ubsan_standalone as a shared library.
Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers.
I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers
are not compatible with each other, and each link has basically a single shared/static choice.
Reviewers: vitalybuka, kcc, rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38525
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315015 91177308-0d34-0410-b5e6-96231b3b80d8
This is a reasonably non-intrusive change, which I've verified
works for both x86 and x64 DevDiv-internal builds.
The idea is to change `bool IsVS2017OrNewer` into a 3-state
`ToolsetLayout VSLayout`. Either a build is DevDiv-internal,
released VS 2017 or newer, or released VS 2015 or older. When looking at
the directory structure, if instead of `"VC"` we see `"x86ret"`, `"x86chk"`,
`"amd64ret"`, or `"amd64chk"`, we recognize this as a DevDiv-internal build.
After we get past the directory structure validation, we use this knowledge
to regenerate paths appropriately. `llvmArchToDevDivInternalArch()` knows how
we use `"i386"` subdirectories, and `MSVCToolChain::getSubDirectoryPath()`
uses that. It also knows that DevDiv-internal builds have an `"inc"`
subdirectory instead of `"include"`.
This may still not be the "right" fix in any sense, but I believe that it's
non-intrusive in the sense that if the special directory names aren't found,
no codepaths are affected. (`ToolsetLayout::OlderVS` and
`ToolsetLayout::VS2017OrNewer` correspond to `IsVS2017OrNewer` being `false`
or `true`, respectively.) I searched for all references to `IsVS2017OrNewer`,
which are places where Clang cares about VS's directory structure, and the
only one that isn't being patched is some logic to deal with
cross-compilation. I'm fine with that not working for DevDiv-internal builds
for the moment (we typically test the native compilers), so I added a comment.
Fixes D36860.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311391 91177308-0d34-0410-b5e6-96231b3b80d8
This commit fixes a bug where clang/llvm doesn't emit an unwind table
for a function when it is marked noexcept. Without this patch, the
following code terminates with an uncaught exception on ARM64:
int foo1() noexcept {
try {
throw 0;
} catch (int i) {
return 0;
}
return 1;
}
int main() {
return foo1();
}
rdar://problem/32411865
Differential Revision: https://reviews.llvm.org/D35693
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310006 91177308-0d34-0410-b5e6-96231b3b80d8
When cross-compiling to Windows using lld, we want the driver to invoke
it as lld-link rather than lld-link.exe. On Windows, the LLVM fs
functions take care of adding the .exe suffix where necessary, so we can
just drop the addition in the toolchain entirely.
Differential Revision: https://reviews.llvm.org/D33923
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304761 91177308-0d34-0410-b5e6-96231b3b80d8
clang-cl works best when the user runs vcvarsall to set up
an environment before running, but even this is not enough
on VC 2017 when cross compiling (e.g. using an x64 toolchain
to target x86, or vice versa).
The reason is that although clang-cl itself will have a
valid environment, it will shell out to other tools (such
as link.exe) which may not. Generally we solve this through
adding the appropriate linker flags, but this is not enough
in VC 2017.
The cross-linker and the regular linker both link against
some common DLLs, but these DLLs live in the binary directory
of the native linker. When setting up a cross-compilation
environment through vcvarsall, it will add *both* directories
to %PATH%, so that when cl shells out to any of the associated
tools, those tools will be able to find all of the dependencies
that it links against. If you don't do this, link.exe will
fail to run because the loader won't be able to find all of
the required DLLs that it links against.
To solve this we teach the driver how to spawn a process with
an explicitly specified environment. Then we modify the
PATH before shelling out to subtools and run with the modified
PATH.
Patch by Hamza Sood
Differential Revision: https://reviews.llvm.org/D30991
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298098 91177308-0d34-0410-b5e6-96231b3b80d8
2017 changes the way you find an installed copy of
Visual Studio as well as its internal directory layout.
As a result, clang-cl was unable to find VS2017 even
when you had run vcvarsall to set up a toolchain
environment. This patch updates everything for 2017
and cleans up the way we handle a tiered search a la
environment -> installation -> PATH for which copy
of Visual Studio to bind to.
Patch originally by Hamza Sood, with some fixups for landing.
Differential Revision: https://reviews.llvm.org/D30758
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297851 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297250 91177308-0d34-0410-b5e6-96231b3b80d8
Nico Weber