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
llvm-svn: 326744
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.
llvm-svn: 315536
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
llvm-svn: 315530
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
llvm-svn: 315107
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
llvm-svn: 315015
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.
llvm-svn: 311391
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
llvm-svn: 310006
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
llvm-svn: 304761
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
llvm-svn: 298098
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
llvm-svn: 297851
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
llvm-svn: 297250
Reid Kleckner