Eric Fiselier 7ffcd984c4 LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()" ... Patch by Arthur O'Dwyer. Reviewed as https://reviews.llvm.org/D47344 new_delete_resource().allocate(n, a) has basically two permissible results: * Return an appropriately sized and aligned block. * Throw bad_alloc. Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was to return an appropriately sized but inappropriately under-aligned block. This is now fixed. (This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't trust the default resource to return appropriately aligned blocks, pretty much everything breaks. For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.) llvm-svn: 355763		2019-03-09 00:38:19 +00:00
..
benchmarks
cmake
docs
fuzzing
include	Work around dllimport bug with exclude_from_explicit_instantiation.	2019-03-08 23:59:29 +00:00
lib	Revert "[libc++] Do not force building with -fPIC"	2019-03-08 23:27:46 +00:00
src	LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()"	2019-03-09 00:38:19 +00:00
test	Fix PR41017 - Build failure with _LIBCPP_DEBUG=0 and non-const-ref	2019-03-08 22:58:59 +00:00
utils	[libc++] Only add dylib-related features when using the system's libc++	2019-03-05 22:42:45 +00:00
www	LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()"	2019-03-09 00:38:19 +00:00
.arcconfig
.clang-format
.gitignore
appveyor-reqs-install.cmd
appveyor.yml
CMakeLists.txt	Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"	2019-03-08 20:33:55 +00:00
CREDITS.TXT
LICENSE.TXT
NOTES.TXT
TODO.TXT