This allows passing parameters to the test suites without using
LLVM_LIT_ARGS. The problem is that we sometimes want to set some
Lit arguments on the CMake command line, but the Lit parameters in
a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS,
the command-line entry overrides the cache one, and the parameters
set by the cache are ignored.
This fixes a current issue with the build bots that they completely
ignore the 'std' param set by Lit, because other Lit arguments are
provided via LLVM_LIT_ARGS on the CMake command-line.
As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.
[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
The integration between CMake and executor selection in the new format
wasn't very flexible -- only the default executor and SSH executors were
supported.
This patch makes it possible to specify arbitrary executors with the new
format. With the new testing format, a custom executor is just a script
that gets called with a command-line to execute, and some arguments like
--env, --codesign_identity and --execdir. As such, the default executor
is just run.py.
Remote execution with the SSH executor can be achived by specifying
LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary
scripts can be provided.
Instead of passing file dependencies individually, assume that the
whole content of the unique test directory is a dependency. This
simplifies the test harness significantly, by making %T the directory
that contains everything required to run a test. This also removes the
need for the %{file_dependencies} substitution, which is removed by this
patch.
Furthermore, this patch also changes the harness to execute tests locally
inside %T, so as to avoid creating a separate directory for no purpose.
This clarifies the difference between test for exception support in
libc++abi tests and support for exceptions built into libc++abi.
This also removes the rather confusing similarity between the
_LIBCXXABI_NO_EXCEPTIONS and LIBCXXABI_HAS_NO_EXCEPTIONS macros.
Finally, TEST_HAS_NO_EXCEPTIONS is also detected automatically based
on -fno-exceptions, so it doesn't have to be specified explicitly
through Lit's compile_flags.
0e04342ae0 simplified exceptions-related configurations for libc++abi
and libunwind by reusing the logic in libc++. However, it missed the fact
that libc++abi and libunwind were overriding libc++'s handling of exceptions.
This commit removes special handling in libc++abi and libunwind to use
the logic in libc++, which is the right one.
First, libc++abi doesn't need to add the no-exceptions Lit feature itself,
since that is already done in the config.py for libc++, which it reuses.
Specifically, config.enable_exceptions is set based on @LIBCXXABI_ENABLE_EXCEPTIONS@
in libc++abi's lit.cfg.in, and libc++'s config.py handles that correctly.
Secondly, libunwind's LIBUNWIND_ENABLE_EXCEPTIONS is never set (it's
probably a remnant of copy-pasting code between the runtime libraries),
so the library is always built with exceptions disabled (which makes
sense since it implements the runtime support for exceptions).
Conversely, the test suite is always run with exceptions enabled
(not sure why), but that is preserved by the default behavior of
libc++'s config.py.
Since <unwind.h> is in the SDK, not in /usr/include, the XFAILs must
be predicated on the compiler version (ideally even on the SDK version)
instead of the target system version.
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
Slightly older Clangs seem to think they are more clever than they really
are, and they think the code can never be executed. The code can actually
be executed in case the exception runtime is mis-implemented, which is
exactly what this test is testing. This commit just disables the spurious
warning.
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.
Differential Revision: https://reviews.llvm.org/D78370
The new format should be equivalent to the old format, and it is now the
default format when running the libc++ tests. This commit changes the
libc++abi tests to use the new format by default too. If unexpected failures
are discovered, it should be fine to revert this commit until they are
addressed.
Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.
The LitConfig is shared across the whole test suite. However, since
enabling recursive expansion can be a breaking change for some test
suites, it's important to confine the setting to test suites that
enable it explicitly.
Note that other issues were raised with the way recursiveExpansionLimit
operates. However, this commit simply moves the setting to the right
place -- the mechanism by which it works can be improved independently.
Differential Revision: https://reviews.llvm.org/D77415
This new test format is simpler and more flexible. It creates Lit ShTests
on the fly that reuse existing substitutions (like %{cxx}) instead of
having complex logic in Python to run the tests. This has the benefit
that virtually no coding is required to customize how the test suite is
run -- one can achieve pretty much anything by defining the appropriate
substitutions in a simple lit.cfg file.
For example, in order to run the tests on an embedded device after
building with a specific SDK, one can set the %{cxx} and %{compile_flags}
substitutions to use that SDK, and the %{exec} substitution to the ssh.py
script currently used for .sh.cpp tests with a remote executor. Dealing with
the SSHExecutor becomes unnecessary, since all tests are treated like ShTests.
As a side effect of this design, configuration files for the test
suite can be as simple as:
config.substitutions.append(('%{cxx}', '<path-to-compiler>'))
config.substitutions.append(('%{compile_flags}', '<flags>'))
config.substitutions.append(('%{link_flags}', '<flags>'))
config.substitutions.append(('%{exec}', '<script-to-execute>'))
This should allow storing lit.cfg files for various configurations
directly in the repository instead of relying on complicated logic
in config.py to set up the right flags. I've found numerous problems
in that logic in the past years, and it seems like having simple and
explicit configuration files for the configurations we support is
going to solve most of these problems. Specifically, I am hoping to
store configuration files for testing other Standard Libraries in
the repository.
Improving the interaction with the test suite configuration is still a
work in progress, so for now this test format reuses the substitutions and
available features that are set up by the current config.py.
This new test format should support pretty much everything that the current
test format supports, however it will not be enabled by default at first to
make sure we're satisfied with it. For a short period of time, the new format
will require `--param=use_new_format=True` to be enabled, however it is a very
short term goal to replace the current testing format entirely and to simplify
the configuration accordingly.
Differential Revision: https://reviews.llvm.org/D77338
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
This is a re-application of f383fb40b1, wich was reverted in 04d48111b
because the build bots had not been updated yet. The build bot configurations
have now been updated not to use the deprecated targets, and I verified
that they were using the non-deprecated targets, so we should be good
unless I missed a bot.
Differential Revision: https://reviews.llvm.org/D76104
lit is not very clever when it performs substitution on RUN lines. It
simply looks for a match anywhere in the line (without tokenization)
and replaces it by the expansion. This means that a RUN line containing
e.g. `-verify-ignore-unexpected=note` wouod be expanded to
`-verify-ignore-unexpected=<substitution for not>e`, which is
surprising and nonsensical.
It also means that something like `%compile_module` could be expanded
to `<substitution-for-%compile>_module` or to the correct substitution,
depending on the order in which substitutions are evaluated by lit.
To avoid such problems, it is a good habit to delimit custom substitutions
with some token. This commit does that for all substitutions used in the
libc++ and libc++abi test suites.
This reverts commit f383fb40b. It looks like several of our build bots
are still using the legacy target names, so we'll change those before
we commit this change again.
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
There's no doubt this commit will break some CI systems, however the
fix is trivial.
Differential Revision: https://reviews.llvm.org/D76104
These names have been changed from CamelCase to camelCase, but there were
many places (comments mostly) that still used the old names.
This change is NFC.
builds.
Fix a libc++abi test that was incorrectly checking for threading
primitives even when threading was disabled.
Additionally, temporarily XFAIL some module tests that fail because
the <atomic> header is unsupported but still built as a part of the
std module.
To properly address this libc++ would either need to produce a different
module.modulemap for single-threaded configurations, or it would need
to make the <atomic> header not hard-error and instead be empty
for single-threaded configurations
Summary:
Right now the only way to force libc++abi tests to link with the static version of libc++abi is to set `LIBCXXABI_ENABLE_SHARED` to `OFF`. However, this doesn't work when libc++abi is built as standalone project because of [this](54c5224203/libcxxabi/CMakeLists.txt (L503-L519)).
This change allows specifying the version of the library for tests to link with.
This is useful for remote testing, for example, with `SSHExecutor`, where we _have_ to link with libc++abi statically.
Two new CMake options are introduced here: `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI` and `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXX`. They can be set to `OFF` to tell the test utility to link tests with the static libraries.
It shouldn't break anything, because the default values of these options are set such that the test utility will behave the same way.
Reviewers: EricWF, mclow.lists, phosek, mehdi_amini, ldionne, jroelofs, bcraig
Subscribers: mgorny, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71894
Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings.
Reviewers: mclow.lists, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68879
llvm-svn: 375307
This implements demangling support for the mangling extensions specified
in https://github.com/itanium-cxx-abi/cxx-abi/pull/85, much of which is
implemented in Clang r359967 and r371004.
Specifically, this provides demangling for:
* <template-param-decl> in <lambda-sig>
* <template-param> with non-zero level
* lambda-expression literals (not emitted by Clang yet)
* nullptr literals
* string literals
(The final two seem unrelated, but handling them was necessary in order
to disambiguate between lambda expressions and the other forms of
literal for which we have a type but no value.)
When demangling a <lambda-sig>, we form template parameters with no
corresponding argument, so we cannot substitute in the argument in the
demangling. Instead we invent synthetic names for the template
parameters (eg, '[]<typename $T>($T *x)').
llvm-svn: 371273
The threaded cxa guard test attempted to test multithreaded waiting
by lining up a bunch of threads at a held init lock and releasing them.
The test initially wanted each thread to observe the lock being held,
but some threads may arive too late.
This patch cleans up the test and relaxes the restrictions.
llvm-svn: 359785
This patch does three main things:
(1) It re-writes the cxa guard implementation to make it testable.
(2) Adds support for recursive init detection on non-apple platforms.
(3) It adds a futex based implementation.
The futex based implementation locks and notifies on a per-object basis, unlike the
current implementation which uses a global lock for all objects. Once this patch settles
I'll turn it on by default when supported.
llvm-svn: 359060
Summary:
Ensure we re-export __cxa_throw_bad_array_new_length and
__cxa_uncaught_exceptions from libc++, since they are now
provided by libc++abi.
Doing this allows us to stop linking explicitly against libc++abi in
the libc++abi tests, since libc++ re-exports all the necessary symbols.
However, there is one caveat to that. We don't want libc++ to re-export
__cxa_uncaught_exception (the singular form), since it's only provided
for backwards compatibility. Hence, for the single test where we check
this backwards compatibility, we explicitly link against libc++abi.
PR27405
PR22654
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60424
llvm-svn: 358690
We're building tests with -nostdlib which means that we need to
explicitly include the builtins library. When using libgcc (default)
we can simply include -lgcc_s on the link line, but when using
compiler-rt builtins we need a complete path to the builtins library.
This path is already available in CMake as <PROJECT>_BUILTINS_LIBRARY,
so we just need to pass that path to lit and if config.compiler_rt is
true, link it to the test.
Prior to this patch, running tests when compiler-rt is being used as
the builtins library was broken as all tests would fail to link, but
with this change running tests when compiler-rt bultins library is
being used should be supported.
Differential Revision: https://reviews.llvm.org/D56701
llvm-svn: 353208
There are several changes:
- Don't stringify Pythonized bools (that's why we're Pythonizing them)
- Support specifying target and sysroot via CMake variables
- Use consistent spelling for --target, --sysroot, --gcc-toolchain
llvm-svn: 353137
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
I copied the sanitizer-related logic in libcxx/lib/CMakeLists.txt. In
the future, it would be great to avoid duplicating this logic in the
compiler, libc++ and libc++abi.
Reviewers: EricWF
Subscribers: mgorny, christof, dexonsmith, libcxx-commits, davide
Differential Revision: https://reviews.llvm.org/D53028
llvm-svn: 344191
Patch by Ryan Prichard
If the destination type does not derive from the static type, we can skip
the search_above_dst call, but we still need to run the
!does_dst_type_point_to_our_static_type block of code. That block of code
will increment info->number_to_dst_ptr to 2, and because dest isn't derived
from static, the cast will ultimately fail.
Fixes PR33439
Reviewed as https://reviews.llvm.org/D36447
llvm-svn: 332767
This adds the test which was mistakenly not committed in r332763.
Patch by Ryan Prichard
Propagate the found_our_static_ptr and found_any_static_type flags from
__vmi_class_type_info::search_above_dst to its caller.
Fixes PR33425 and PR33487
Reviewed as https://reviews.llvm.org/D36446
llvm-svn: 332764
This is a follow-up change to r331150. The CL moved the macro from individual
file to build file, but the macro is missed in a test config file.
https://reviews.llvm.org/D46385
Patch from Taiju Tsuiki <tzik@chromium.org>!
llvm-svn: 331450
_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS is currently used to
bring back std::unexpected, which is removed in C++17, but still needed
for libc++abi for backward compatibility.
This macro used to define in cxa_exception.cpp only, but actually
needed for all sources that touches exceptions.
So, a build-system-level macro is better fit to define this macro.
https://reviews.llvm.org/D46056
Patch from Taiju Tsuiku <tzik@chromium.org>!
llvm-svn: 331150
Strictly in a conversion operator's type, a <template-param> refers to a
<template-arg> that is further ahead in the mangled name. Instead of
doing a second parse to resolve these, introduce a
ForwardTemplateReference Node and back-patch the referenced
<template-arg> when we're in the right context.
This is also a correctness fix, previously we would only do a second
parse if the <template-param> was out of bounds in the current set of
<template-args>. This lead to misdemangles (gasp!) when the conversion
operator was a member of a templated struct, for instance.
llvm-svn: 328464
Rather than eagerly propagating up parameter pack sizes in Node ctors,
find the parameter pack size during printing. This is being done to
support back-patching forward referencing <template-param>s.
llvm-svn: 328463
This commit cleans up the expression parser, using a new style:
- parse* functions now return Node pointers.
- The mangled name is now held in Db and accessed with look() and consume()
- LLVM coding style
This style is meant to avoid the 2 most common types of bugs in the
old demanger, namely misusing the Names stack (ie, calling back() on
empty) and going out of bounds on the mangled name. I also think it
makes the demangler a lot cleaner.
Differential revision: https://reviews.llvm.org/D41887
llvm-svn: 324111
This commit changes how variadic templates are represented in the
demangler, in order to fix some longstanding bugs. Now instead of
expanding variadic templates during parsing, the expansion is done
during printing by reusing the unexpanded AST. This allows the
demangler to handle cases where multiple packs contribute to a single
production, and correctly handle "Dp" and "sp" productions, which
corrispond to pack expansions in type and expression contexts.
Differential revision: https://reviews.llvm.org/D41885
llvm-svn: 323906
This patch updates libc++abi's HandleOutOfTreeLLVM.cmake to match
libc++'s -- and more importantly, to fix a bug where llvm-lit wasn't
found/created when libc++abi was built out-of-tree. This prevented
the test suite from running.
llvm-svn: 322768
The demangler now demangles by producing an AST, then traverses that
AST to produce a demangled name. This is done for performance reasons,
now the demangler doesn't manuiplate std::strings, which hurt
performance and caused string operations to be inlined into the
parser, leading to large code size and stack usage.
Differential revision: https://reviews.llvm.org/D35159
llvm-svn: 309340
The problem was that if base_name() was called from a context without
an actual base name, it could gulp up the entire string, which can
result in recursive duplications. The fix is to be more strict as to
what qualifies as a base name.
Differential revision: https://reviews.llvm.org/D33637
llvm-svn: 304113
Summary:
Previously if we parsed a constructor then we set parsed_ctor_dtor_cv
to true and never reseted it. This causes issue when a template argument
references a constructor (e.g. type of lambda defined inside a
constructor) as we will have the parsed_ctor_dtor_cv flag set what will
cause issues when parsing later arguments.
Reviewers: EricWF, compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33385
llvm-svn: 303737
The problem is that multiple types could have been parsed from parse_type(),
which the lamdba parameter parsing didn't handle.
Differential revision: https://reviews.llvm.org/D33368
llvm-svn: 303718
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302978 and r302981, which were reverted in r303016
because a libcxx test was failing on an AArch64 bot. I also modified the
libcxxabi test case to check the alignment of the pointer returned by
__cxa_allocate_exception rather than compiling the test with -O1 and
checking whether it segfaults.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 303175
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302763 with fixes to RUN lines in the test case.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302978
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302763
This test fails on ARM bare-metal targets because it assumes the Itanium ABI,
whereas EHABI requires the exception address to be 8-byte aligned.
I was a bit puzzled at first because this should've failed on the public
arm-linux builder too. I think the reason it passes there is because we don't
include libunwind headers in the include path when running the libcxxabi tests,
so the system unwind.h gets picked up.
Reviewers: rengolin, EricWF
Differential revision: https://reviews.llvm.org/D31178
llvm-svn: 299435
Summary: It's now completely empty, so we can remove it entirely.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31502
llvm-svn: 299129
Summary:
In 32 bit builds on a 64 bit system `std::malloc` does not return correctly aligned memory. This leads to undefined behavior.
This patch switches to using `posix_memalign` to allocate correctly aligned memory instead.
Reviewers: mclow.lists, danalbert, jroelofs, compnerd
Reviewed By: compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25417
llvm-svn: 296952
These tests embed calls to exceptions-related symbols from the abi library,
which are absent in the no-exceptions variant. The tests need to be marked
as unsupported for the no-exceptions configuration.
llvm-svn: 296344
When checking if the type is a r-value ref, we would not do a complete
check. This would result in us treating a trailing parameter reference
`&)` as a r-value ref, and improperly inject the cv qualifier on the
type. We now correctly demangle the type `KFvRmE` as a constant
function rather than a constant reference.
Fixes PR31741!
llvm-svn: 292973
Fix an off-by-one case which would destroy the final parameter in a
CV-qualified function type with a reference. We still get the CV
qualification incorrect, but at least we do not clobber the type name
any longer.
Partially fixes PR31741.
llvm-svn: 292963
Pending LIT changes are about to remove the REQUIRES-ANY keyword
in place of supporting boolean && and || within "REQUIRES". This
patch prepares libc++ for that change so that when applied
the bots don't lose their mind.
llvm-svn: 292906
This test contained an implicit conversion from nullptr to bool.
Clang warns about this but the test had supressed that warning.
However GCC diagnoses the same code as an error and requires
-fpermissive to accept it.
This patch fixes both the warning and the error by explicitly
converting the pointer to bool.
llvm-svn: 292638
The Itanium ABI [1] specifies that __cxa_demangle accept either:
1) symbol names, which start with "_Z"
2) type manglings, which do not start with "_Z"
r286788 erroneously assumes that it should only handle symbols, so this patch
reverts it and adds a counterexample to the testcase.
1: https://mentorembedded.github.io/cxx-abi/abi.html#demangler
Reviewers: zygoloid, EricWF
llvm-svn: 292418
+ Now that libcxxabi shares the same threading API as libcxx, a whole
chunk of code in src/config.h is made redundant (I missed this earlier).
+ r291275 split off the externalized-thread-api libcxx configuration from the
external-thread-library libcxx configuration. libcxxabi should follow the
same approach.
llvm-svn: 291440
r281179 Introduced an externally threaded variant of the libc++ library. This
patch adds support for a similar library variant for libc++abi.
Differential revision: https://reviews.llvm.org/D27575
Reviewers: EricWF
llvm-svn: 290888
The macOS thread-local variable finalizer routines do not handle the
case where a termination function registers another termination function
correctly, causing this test to fail. I've filed a radar for this;
mark the test XFAIL in the meantime. See [1] for more details.
[1] http://lists.llvm.org/pipermail/cfe-dev/2016-November/051376.html
Differential Revision: https://reviews.llvm.org/D27434
llvm-svn: 289513
Louis Dionne