FailedChanges

Summary

  1. [Driver] Support libc++ in MSVC (details)
  2. [MinGW] Mark a number of library functions unavailable for mingw targets (details)
  3. [Windows] Use TerminateProcess to exit without running destructors (details)
Commit b604301be3559fb85a11779db79fc9bda4b62bce by phosek
[Driver] Support libc++ in MSVC

This implements support for using libc++ headers and library in the MSVC
toolchain.  We only support libc++ that is a part of the toolchain, and
not headers installed elsewhere on the system.

Differential Revision: https://reviews.llvm.org/D101479
The file was addedclang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
The file was addedclang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep
The file was addedclang/test/Driver/msvc-libcxx.cpp
The file was addedclang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/c++/v1/.keep
The file was addedclang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep
The file was addedclang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
The file was modifiedclang/lib/Driver/ToolChains/MSVC.cpp
Commit c5638a71d805330294e9b6e2c670e1ed7420b63a by martin
[MinGW] Mark a number of library functions unavailable for mingw targets

These functions were marked unavailable for MSVC targets before,
within an "T.isOSWindows() && !T.isOSCygMing()" block, but these ones
are unavailable on MinGW targets too.

This avoids generating calls to stpcpy for MinGW targets, which has
been happening since 6dbf0cfcf789365493f70ae69df8a7a59be41c75 (in
some cases).

This fixes https://github.com/mstorsjo/llvm-mingw/issues/201.

Differential Revision: https://reviews.llvm.org/D102946
The file was modifiedllvm/test/Transforms/InstCombine/sprintf-1.ll
The file was modifiedllvm/lib/Analysis/TargetLibraryInfo.cpp
Commit b4fd512c36ca344a3ff69350219e8b0a67e9472a by martin
[Windows] Use TerminateProcess to exit without running destructors

If exiting using _Exit or ExitProcess, DLLs are still unloaded
cleanly before exiting, running destructors and other cleanup in those
DLLs. When the caller expects to exit without cleanup, running
destructors in some loaded DLLs (which can be either libLLVM.dll or
e.g. libc++.dll) can cause deadlocks occasionally.

This is an alternative to D102684.

Differential Revision: https://reviews.llvm.org/D102944
The file was modifiedllvm/include/llvm/Support/Process.h
The file was modifiedllvm/lib/Support/Windows/Process.inc
The file was modifiedllvm/lib/Support/Unix/Process.inc
The file was modifiedllvm/lib/Support/Process.cpp