summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test
diff options
context:
space:
mode:
authorEric Fiselier <eric@efcs.ca>2019-03-09 00:38:19 +0000
committerEric Fiselier <eric@efcs.ca>2019-03-09 00:38:19 +0000
commit7ffcd984c4de54dea96049b9cb6a74c9e9b84c1e (patch)
treef005738dd727154282520d1443c442c3a62f7ca1 /lldb/packages/Python/lldbsuite/test
parentc5bfa3dafb3e7ccc871734a96b7a9188868d925a (diff)
downloadbcm5719-llvm-7ffcd984c4de54dea96049b9cb6a74c9e9b84c1e.tar.gz
bcm5719-llvm-7ffcd984c4de54dea96049b9cb6a74c9e9b84c1e.zip
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
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud