Summary:
Excerpt from [atomics.types.operations.req]/21:
> When only one memory_order argument is supplied, the value of
> success is order, and the value of failure is order except that a
> value of memory_order_acq_rel shall be replaced by the value
> memory_order_acquire and a value of memory_order_release shall be
> replaced by the value memory_order_relaxed.
Clean up some copy pasta while I'm here (someone added a return
statement to a void function).
Reviewers: EricWF, jroelofs, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6632
llvm-svn: 225280
The SFINAE on the function __mu(Fn, Args...) that evaluates nested bind
expressions always tries to deduce the return type for Fn(Args...) even when Fn
is not a nested bind expression. This can cause hard compile errors when the
instantation of Fn(Args...) is ill-formed. This patch prevents the instantation
of __invoke_of<Fn, Args...> unless Fn is actually a bind expression.
Bug reportand patch from Michel Morin.
http://llvm.org/bugs/show_bug.cgi?id=22003
llvm-svn: 224753
It might be implicitly included by <pthread.h> (and that's why it worked
so far), but it's not guaranteed (for example, this is not the case with
newlib).
llvm-svn: 223661
Summary:
The NaCl sandbox doesn't allow opening files under /dev, but it offers an API which provides the same capabilities. This is the same random device emulation that nacl_io performs for POSIX support, but nacl_io is an optional library so libc++ can't assume that device emulation will be performed. Note that NaCl only supports /dev/urandom, not /dev/random.
This patch also cleans up some of the preprocessor #endif, and fixes the test for Win32 (it accepts any token, and would therefore never throw regardless of the token provided).
Test Plan: ninja check-libcxx
Reviewers: dschuff, mclow.lists, danalbert
Subscribers: jfb, cfe-commits
Differential Revision: http://reviews.llvm.org/D6442
llvm-svn: 223068
Summary:
The size of the vector is being increased by `__n` during the call to `__move_range` and not by 1.
This fixes a test failure in `containers/sequences/vector/vector.modifiers/insert_iter_size_value.pass.cpp` when using ASAN.
Reviewers: danalbert, kcc, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6264
llvm-svn: 222014
Summary:
http://llvm.org/bugs/show_bug.cgi?id=18345
Tuple's constructor and assignment operators for "tuple-like" types evaluates __make_tuple_types unnecessarily. In the case of a large array this can blow the template instantiation depth.
Ex:
```
#include <array>
#include <tuple>
#include <memory>
typedef std::array<int, 1256> array_t;
typedef std::tuple<array_t> tuple_t;
int main() {
array_t a;
tuple_t t(a); // broken
t = a; // broken
// make_shared uses tuple behind the scenes. This bug breaks this code.
std::make_shared<array_t>(a);
}
```
To prevent this from happening we delay the instantiation of `__make_tuple_types` until after we perform the length check. Currently `__make_tuple_types` is instantiated at the same time that the length check .
Test Plan: Two tests have been added. One for the "tuple-like" constructors and another for the "tuple-like" assignment operator.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: K-ballo, cfe-commits
Differential Revision: http://reviews.llvm.org/D4467
llvm-svn: 220769
Summary: This fixes ODR violations in C++03 mode in test/localization/locale.stdcvt. The special case for linux was introduced in 2010 before clang always defined __char16_t and __char32_t.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5930
llvm-svn: 220716
The comma operators in the test iterators give better error messages when they
are deleted as opposed to not defined. Delete these functions when possible.
llvm-svn: 220715
Summary:
An evil user might overload operator comma. Use a void cast to make sure any user overload is not selected.
Modify all the test iterators to define operator comma.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5929
llvm-svn: 220706
This essentially re-does r194825 and makes it possible to run clang
with libc++ without having to install it, even if you don't have any
version of libc++ installed in /usr/.
This behaviour broke in r210577/r211629, which fixed pr18681.
llvm-svn: 220489
Summary:
This patch is very closely related to D4859. Please see http://reviews.llvm.org/D4859 for more information.
This patch adds support for "fancy" pointers and allocators to promise and packaged_task. The changes made to support this are exactly the same as in D4859.
Test Plan: "fancy" pointer tests were added to each constructor affected by the change.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4862
llvm-svn: 220471
Summary:
This patch add support for "fancy pointers/allocators" as well as fixing support for shared_pointer and "minimal" allocators.
Fancy pointers are class types that meet the NullablePointer requirements. In our case they are created by fancy allocators. `support/min_allocator.h` is an archetype for these types.
There are three types of changes made in this patch:
1. `_Alloc::template rebind<T>::other` -> `__allocator_traits_rebind<_Alloc, T>::type`. This change was made because allocators don't need a rebind template. `__allocator_traits_rebind` is used instead of `allocator_traits::rebind` because use of `allocator_traits::rebind` requires a workaround for when template aliases are unavailable.
2. `a.deallocate(this, 1)` -> `a.deallocate(pointer_traits<self>::pointer_to(*this), 1)`. This change change is made because fancy pointers aren't always constructible from raw pointers.
3. `p.get()` -> `addressof(*p.get())`. Fancy pointers aren't actually a pointer. When we need a "real" pointer we take the address of dereferencing the fancy pointer. This should give us the actual raw pointer.
Test Plan: Tests were added using `support/min_allocator.h` to each affected shared_ptr overload and creation function. These tests can only be executed in C++11 or greater since min_allocator is only available then. A extra test was added for the non-variadic versions of allocate_shared.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4859
llvm-svn: 220469
Delay instantiation of `__numeric_type` within <cmath>,
don't instantiate it when the `is_arithmetic` conditions do not hold as it causes
errors with user-defined types with ambiguous conversions. Fixes PR21083.
llvm-svn: 219998
With clang, the header atomic requires __has_feature(cxx_atomic), which is only
true in c++11 mode. Because of this, when using modules in c++98 with libc++
compilation of the std module would fail without this change, PR21002.
(With gcc, only gcc4.7+ is needed, no c++11. But gcc doesn't have modules yet,
and the module.modulemap language can't express things like "this is only
required if the compiler is clang". If gcc gets module support, we'd probably
have a module.modulemap file for each compiler that libc++ supports?)
llvm-svn: 218372
GCC 4.9 fails to inline these functions at -O1 because they are used
indirectly. Declare them as inline instead of always_inline. Discussion
in GCC bugreport: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63220
llvm-svn: 217961
If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-has-no-threads to your lit commnad line.
http://reviews.llvm.org/D3969
llvm-svn: 217271
Turning off explicit template instantiation leads to a pretty
significant build time and code size cost. We're better off dealing
with ABI incompatibility issues that come up in a less heavy handed
way.
This reverts commit r189610.
llvm-svn: 215740
This patch just adds the required return statements to slice_array::operator=
and mask_array::operator=.
Tests were added to check that the return value is the same as the object assigned
to.
llvm-svn: 215414
Things done in this patch:
1. Make __debug include __config since it uses macros from it.
2. The current method of defining _LIBCPP_ASSERT is prone to redefinitions. Move
the null _LIBCPP_ASSERT definition into the __debug header to prevent this.
3. Remove external <__debug> include gaurds. <__debug> guards almost all of its
contents internally. There is no reason to be doing it externally.
This patch should not change any functionality.
llvm-svn: 215332
gcc 4.7 and above has atomic built-ins which slightly different APIs
from those provided by clang. Add proxy functions that wrap the gcc
built-ins to produce a symbol that is API equivalent to the clang
built-ins. This allows libc++'s atomic library to be used with gcc-4.7
and newer.
Patch contributed by Albert Wong.
llvm-svn: 215305
Summary: This patch moves the SFINAE for __is_destructor_welformed out of the function template parameters. type_traits must compile in c++03 mode since it is included in c++03 headers.
Test Plan: No tests have been added.
Reviewers: danalbert, mclow.lists
Reviewed By: danalbert
Subscribers: K-ballo, cfe-commits
Differential Revision: http://reviews.llvm.org/D4735
llvm-svn: 214422
__get_classname() and __bracket_expression were assuming that
char_class_type was ctype_base::mask rather than using
regex_traits<_CharT>::char_class_type.
This change allows char_class_type to be defined to something other than
ctype_base::mask so that the implementation will still work for
platforms with an 8-bit ctype mask (such as Android and OpenBSD).
llvm-svn: 214201
Summary: The polymorphic allocator implementation would greatly benefit by defining virtual functions in the dynlib instead of inline. In order to do that some types are going to have to be available outside of c++1y. This is the first step.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4554
llvm-svn: 213889
std::make_heap is currently implemented by iteratively applying a
siftup-type algorithm. Since sift-up is O(ln n), this gives
std::make_heap a worst case time complexity of O(n ln n).
The C++ standard mandates that std::make_heap make no more than O(3n)
comparisons, this makes our std::make_heap out of spec.
Fix this by introducing an implementation of __sift_down and switch
std::make_heap to create the heap using it.
This gives std::make_heap linear time complexity in the worst case.
This fixes PR20161.
llvm-svn: 213615
Summary:
This patch adds the `<experimental/utility>` header as specified in the latest draft of the library fundamentals TS.
`<experimental/utility>` only contains `class erased_type`.
This patch also updates the documentation to list the `erased_type` class as "initial implementation complete".
Test Plan:
Three test cases where added:
1. Test that `_LIBCPP_VERSION` is defined.
2. Test that `<utility>` has been included.
3. Test that `erased_type` is in the correct namespace and is constexpr default constructible.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4510
llvm-svn: 213226
Mark the base classes for time_get_byname and time_get as _LIBCPP_TYPE_VIS_ONLY
rather than _LIBCPP_TYPE_VIS. These base classes are templated types and cannot
be stored with export dll storage.
Fixes compilation with _LIBCPP_DLL for Windows when the time_get and
time_get_byname classes are used.
llvm-svn: 213116
libc++ currently relies on undefined initialization order of global
initializers when using gcc:
1. __start_std_streams in iostream.cpp calls locale:🆔:_init, which assigns
an id to each locale::facet in an initializer
2. Every facet has a static locale::id id, whose constructor sets the facet's
id to 0
If 2 runs after 1, it clobbers the facet's assigned consecutive id, causing
exceptions to be thrown when e.g. running code like "cout << endl".
To fix this, let _LIBCPP_CONSTEXPR evaluate to "constexpr" instead of nothing
with gcc. locale::id's constructor is marked _LIBCPP_CONSTEXPR, which ensures
that it won't get an initializer that could potentially run after the
iostream.cpp initializer. (This remains broken when building with msvc.)
Also switch constexpr-specific code in bitset to use __SIZEOF_SIZE_T__ instead
of __SIZE_WIDTH__, because gcc doesn't define the latter.
Pair-programmed/debugged with Dana Jansens.
llvm-svn: 210188
(clang doesn't complain about this, but gcc does. This is necessary for a
follow-up patch that will enable _LIBCPP_CONSTEXPR for gcc.)
llvm-svn: 209888
r207606 changed the __need_foo macros to behave like they do with gcc: If they
are set, _only_ the __need_foo stuff gets defined. As a consequence, cstddef
no longer defined "offsetof". It looks like the __need_foo defines aren't
needed anymore, so just remove them.
Fixes PR19723.
llvm-svn: 208942
compatibility to libstdc++. Move the implementation into a header for
easier sharing with libc++abi. Merge a number of improvements from that
version. Provide a POD definition for <stdexcept>'s public use to avoid
cast dances. Discussed with Marshall Clow.
llvm-svn: 207695
libc++ will not call address_sanitizer to detect addressing errors in the
standard library containers. This is a negative macro to enable users to
disable the libc++ checks even if they are compiling with address sanitizer
enabled by defining this macro.
At the present time, there is no code in libc++ that looks at this macro.
That will come soon. This is just infrastructure.
llvm-svn: 206184
It's identical to name() these days. (At one point it avoided masking
of the RTTI uniqueness bit because ARM64 ignored it architecturally,
but no longer).
llvm-svn: 205518
ARM64 generates RTTI with hidden visibility, which means that typeinfo
must be compared char-by-char since it's not guaranteed to be uniqued
across the whole program.
llvm-svn: 205139
This is as straightforward as it sounds, a renamed from shared_mutex to
shared_timed_mutex.
Note that libcxx .dylib and .so files built with c++14 support need to
be rebuilt.
llvm-svn: 204078
Instead, define explicit specializations for the basic types listed in
the SGI documentation. This solves two problems:
1) Helps avoid silent ODR violations caused by the absence of a
user-supplied __gnu_cxx::hash specialization in cases where a std::hash
specialization exists (e.g. for std::string).
2) __gnu_cxx::hash semantics are slightly different to those of
std::hash (for example, the former may dereference a pointer argument)
so it is inappropriate for __gnu_cxx::hash to receive std::hash
specializations by default.
Differential Revision: http://llvm-reviews.chandlerc.com/D2747
llvm-svn: 203070
Error 1 error C2681: 'add_rvalue_reference<_Tp*>::type' : invalid expression
type for dynamic_cast c:\libcxx\include\type_traits
This is one more step getting libcxx compile under Visual C++. The patch is
#if defined(_LIBCPP_MSVC) so will affect only this build.
When libcxx can be compiled, it will probably require the current version or
maybe even the next Update of Visual C++ 2013.
Patch by G M!
llvm-svn: 201844
rather than its own type for std::max_align_t. This is particularly
relevant as the types may not be ABI compatible despite users expecting
them to be.
llvm-svn: 201843
with Visual C++ 2013 by making libcxx definition text-identical to yvals.h.
Persumably this definition is for older Visual C++ versions.
In such cases it will still be defined so no functionality change.
Other platforms should not be affected as this is inside
#elif defined(_LIBCPP_MSVC)
Patch by G M!
llvm-svn: 201328
GCC will treat the default function template arguments as a
compilation error if C++0x is not enabled.
This commit workaround the compilation error by moving the
SFINAE check to function argument instead of the template
argument.
llvm-svn: 200523
for libcxx when compiled with Visual C++ on Win32 and Win64.
clang and gcc (MinGW) compilers provide these implementations themselves.
llvm-svn: 198481
GCC does not support strong enum if -std=c++0x is not used.
Without the strong enum, we will see following error:
In file included from libcxx/include/ostream:131:0,
from libcxx/include/sstream:174,
from libcxx/include/complex:247,
from cpp03-headers.cpp:11:
libcxx/include/ios:419:68: error: 'io_errc' is not a class or namespace
libcxx/include/ios:420:66: error: 'io_errc' is not a class or namespace
To workaround this issue, this commit will define
_LIBCPP_HAS_NO_STRONG_ENUMS when we are compiling with
g++ without c++0x.
llvm-svn: 197313
type_traits:3280:31: error: expected primary-expression before 'decltype'
type_traits:3280:29: error: expected ';' at end of member declaration
memory:2415:49: error: function 'std::__1::default_delete<_Tp>::default_delete()'
defaulted on its first declaration must not have an exception-specification
memory:2435:49: error: function 'std::__1::default_delete<_Tp []>::default_delete()'
defaulted on its first declaration must not have an exception-specification
The attached patch defines _LIBCPP_HAS_NO_ADVANCED_SFINAE and
_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS for gcc version < 4.7, making
the library compile with gcc 4.6.4.
llvm-svn: 195431
functions in src/support/win32/locale_win32.cpp and locale_win32.h,
calling upon vsnprintf for which there is a MingW correct alternative.
Note! __USE_MINGW_ANSI_STDIO is not modified in this patch. In order to
use the __mingw version it must be defined before including the MingW
headers.
llvm-svn: 195044
trivial in C++03, thus making it trivial in both C++03 and C++11.
This patch allows one to opt-in/out of this decision with a macro. You can
choose to have the pair copy constructor always be trivial, or always be
non-trivial. The flag controlling this is now _LIBCPP_TRIVIAL_PAIR_COPY_CTOR.
The client can define this flag to 1, and the pair copy constructor will be
trivial (when possible of course), or to 0, and the pair copy constructor will
be nontrivial.
Default settings for this flag are set in <__config> (as usual). With this
commit the default is _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 for all platforms
except __APPLE__, which defaults to _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=0.
llvm-svn: 194742
pair, and a couple of pair-like implementation detail types. The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.
Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors. Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm). This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.
Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members. However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).
During this work a bug was also found and fixed in
is_trivially_constructible.
And there is a minor drive-by fix in <__config> regarding
__type_visibility__.
A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11. This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.
llvm-svn: 194536
The issue this patch seeks to address is that MS's compiler (cl.exe) doesn't support the __attribute__((__weak__)) or __atribute__((__visibility__("default")) syntax; so a solution must be found where cl.exe doesn't see this syntax.
This patch seeks to solve this problem by changing code patterned like this:
__attribute__((__weak__, __visibility__("default")))
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { /*snip*/; return p; }
to code like this:
_LIBCPP_WEAK
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { return p; }
Howard: Thanks for all the comments regarding the default visibility
tag on the definition. I agree it isn't needed, and that there are lots
of other places where it is missing. That being said, I'm not wanting
to rock the boat on that issue right now. So I've added it back to the
definition via _LIBCPP_FUNC_VIS. A later pass dedicated just to this
issue can bring things in to a consistent state one way or the other.
Note that we do not want to have the exact same attributes on the
declaration and defintion in this case. The declaration should not be
marked weak, whereas the definition should (which is what G M's patch
did). I've fully tested on OS X to ensure that the resultant attribute
syntax actually works.
llvm-svn: 192007
The patch touches these files:
locale
array
deque
new
string
utility
vector
__bit_reference
__split_buffer
locale_win32.h
There is no intended functionality change and it is expected that reversing the position of the inline keyword with regard to the other keywords does not change the meaning of anything, least not for apple/Linux etc.
It is intended to make libcxx more consistent with itself and to prevent the 1000 or so
"inline.cpp(3) : warning C4141: 'inline' : used more than once" warnings that MS's cl.exe compiler emits without this patch, i.e. if inline is not the first keyword before a function name etc.
Prefer "inline [other inline related keyword]" over "[other related keyword] inline".
After this patch, libcxx should be consistent to this pattern.
llvm-svn: 191987
iterator, allocator) constructor with the intention of it being
implicitly converted to the allocator type, it is possible for overload
resolution to favour the (iterator, iterator, enable_if) constructor.
Eliminate this possibility by moving the enable_if to one of the
existing arguments and removing the third argument.
llvm-svn: 191145
1. I had been detecting and trapping iterator == and \!= among iterators
in different containers as an error. But the trapping itself is actually
an error.
Consider:
#include <iostream>
#include <vector>
#include <algorithm>
template <class C>
void
display(const C& c)
{
std::cout << "{";
bool first = true;
for (const auto& x : c)
{
if (\!first)
std::cout << ", ";
first = false;
std::cout << x;
}
std::cout << "}\n";
}
int
main()
{
typedef std::vector<int> V;
V v1 = {1, 3, 5};
V v2 = {2, 4, 6};
display(v1);
display(v2);
V::iterator i = std::find(v1.begin(), v1.end(), 1);
V::iterator j = std::find(v2.begin(), v2.end(), 2);
if (*i == *j)
i = j; // perfectly legal
// ...
if (i \!= j) // the only way to check
v2.push_back(*i);
display(v1);
display(v2);
}
It is legal to assign an iterator from one container to another of the
same type. This is required to work. One might want to test whether or
not such an assignment had been made. The way one performs such a check
is using the iterator's ==, \!= operator. This is a logical and necessary
function and does not constitute an error.
2. I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined.
This caused a problem in several of the libc++ tests.
Fixed.
3. There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that
std::basic_string is inoperable. std::basic_string uses __wrap_iterator
to implement its iterators. __wrap_iterator has been rigged up in debug
mode to support vector. But string hasn't been rigged up yet. This means
that one gets false positives when using std::string in debug mode. I've
upped std::string's priority in www/debug_mode.html.
llvm-svn: 187636
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can
also define _MSC_VER, and MSVCRT is not necessarily the only C runtime,
these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned
categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using
_MSC_VER, excluding Clang.
- _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default
when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
llvm-svn: 187593
There are actually two debug modes:
1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1
This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations.
2. -D_LIBCPP_DEBUG2=0
This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity.
llvm-svn: 187369
unordered_set, however it is not complete yet for unordered_multiset,
unordered_map or unordered_multimap. There has been a lot of work done
for these other three containers, however that work was done just to
keep all of the tests passing.
You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a
libc++.dylib that has been compiled with src/debug.cpp. So far, vector
(but not vector<bool>), list, and unordered_set are treated. I hope to
get the other three unordered containers up fairly quickly now that
unordered_set is done.
The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but
not today. This is my second effort at getting debug mode going for
libc++, and I'm not quite yet ready to throw all of the work under the
first attempt away.
The basic design is that all of the debug information is kept in a
central database, instead of in the containers. This has been done as
an attempt to have debug mode and non-debug mode be ABI compatible with
each other. There are some circumstances where if you construct a
container in an environment without debug mode and pass it into debug
mode, the checking will get confused and let you know with a readable
error message. Passing containers the other way: from debug mode out to
a non-debugging mode container should be 100% safe (at least that is the
goal).
llvm-svn: 186991
Marshall Clow