[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 Richard Biener changed: What|Removed |Added Target Milestone|7.5 |8.4 --- Comment #40 from Richard Biener --- The GCC 7 branch is being closed, re-targeting to GCC 8.4.
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #39 from Jonathan Wakely ---
(In reply to dave.anglin from comment #37)
> I believe I changed the glibc value because of the pthread mutex issue.
Aha.
> MALLOC_ABI_ALIGNMENT is defined in pa32-linux.h as follows:
> #define MALLOC_ABI_ALIGNMENT 128
>
> So, the defines are now consistent on linux. The only remaining problem is
> 64-bit hpux where the actual
> malloc alignment is 8 bytes. The resource_adapter.cc test still fails on
I've just committed a change to the resource_adaptor implementation, but I
don't expect it to change the FAIL for hpux yet. I hope the FAILs are fixed for
Solaris now though, and if so then we make the special case apply to 64-bit
hpux too, like so (are these the right macros to check for?):
diff --git a/libstdc++-v3/include/experimental/memory_resource
b/libstdc++-v3/include/experimental/memory_resource
index dde3753fab7..dd6f3099a78 100644
--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -413,7 +413,8 @@ namespace pmr {
do_allocate(size_t __bytes, size_t __alignment) override
{
// Cannot use max_align_t on 32-bit Solaris x86, see PR libstdc++/77691
-#if ! (defined __sun__ && defined __i386__)
+#if ! (defined __sun__ && defined __i386__) \
+ && ! (defined __hpux && defined _LP64)
if (__alignment == alignof(max_align_t))
return _M_allocate(__bytes);
#endif
@@ -439,7 +440,8 @@ namespace pmr {
do_deallocate(void* __ptr, size_t __bytes, size_t __alignment) noexcept
override
{
-#if ! (defined __sun__ && defined __i386__)
+#if ! (defined __sun__ && defined __i386__) \
+ && ! (defined __hpux && defined _LP64)
if (__alignment == alignof(max_align_t))
return (void) _M_deallocate(__ptr, __bytes);
#endif
diff --git
a/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
b/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
index 7dcb408f3f7..d4353ff6464 100644
---
a/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
+++
b/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
@@ -23,7 +23,8 @@
#include
#include
-#if defined __sun__ && defined __i386__
+#if (defined __sun__ && defined __i386__) \
+ || (defined __hpux && defined _LP64)
// See PR libstdc++/77691
# define BAD_MAX_ALIGN_T 1
#endif
> it. Maybe I should change BIGGEST_ALIGNMENT
> and MALLOC_ABI_ALIGNMENT to match the malloc implementation?
I think that makes sense (although it won't change anything until we make the
suggestion from PR 90569 as well, so I'll do that this week).
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #38 from Jonathan Wakely --- Author: redi Date: Wed May 22 20:29:39 2019 New Revision: 271522 URL: https://gcc.gnu.org/viewcvs?rev=271522&root=gcc&view=rev Log: PR libstdc++/77691 fix resource_adaptor failures due to max_align_t bugs Remove the hardcoded whitelist of allocators expected to return memory aligned to alignof(max_align_t), because that doesn't work when the platform's malloc() and GCC's max_align_t do not agree what the largest fundamental alignment is. It's also sub-optimal for user-defined allocators that return memory suitable for any fundamental alignment. Instead use a hardcoded list of alignments that are definitely supported by the platform malloc, and use a copy of the allocator rebound to a POD type with the requested alignment. Only allocate an oversized buffer to use with std::align for alignments larger than any of the hardcoded values. For 32-bit Solaris x86 do not include alignof(max_align_t) in the hardcoded values. PR libstdc++/77691 * include/experimental/memory_resource: Add system header pragma. (__resource_adaptor_common::__guaranteed_alignment): Remove. (__resource_adaptor_common::_Types) (__resource_adaptor_common::__new_list) (__resource_adaptor_common::_New_list) (__resource_adaptor_common::_Alignments) (__resource_adaptor_common::_Fund_align_types): New utilities for creating a list of types with fundamental alignments. (__resource_adaptor_imp::do_allocate): Call new _M_allocate function. (__resource_adaptor_imp::do_deallocate): Call new _M_deallocate function. (__resource_adaptor_imp::_M_allocate): New function that first tries to use an allocator rebound to a type with a fundamental alignment. (__resource_adaptor_imp::_M_deallocate): Likewise for deallocation. * testsuite/experimental/memory_resource/new_delete_resource.cc: Adjust expected allocation sizes. * testsuite/experimental/memory_resource/resource_adaptor.cc: Remove xfail. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/memory_resource trunk/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc trunk/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #37 from dave.anglin at bell dot net --- On 2019-05-22 3:41 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 > > --- Comment #36 from Jonathan Wakely --- > Interesting. Yes, definitely similar ideas. It looks like it was solved > differently though, as config/pa/pa.h has > > #define MALLOC_ABI_ALIGNMENT (TARGET_64BIT ? 128 : 64) > > which should get used by the aligned new code, even without my suggested > change > in PR 90569. > > As an aside, the comment on MALLOC_ABI_ALIGNMENT says "The glibc > implementation > currently provides 8-byte alignment." But glibc malloc was changed to 16-byte > alignment a couple of years ago. I believe I changed the glibc value because of the pthread mutex issue. MALLOC_ABI_ALIGNMENT is defined in pa32-linux.h as follows: #define MALLOC_ABI_ALIGNMENT 128 So, the defines are now consistent on linux. The only remaining problem is 64-bit hpux where the actual malloc alignment is 8 bytes. The resource_adapter.cc test still fails on it. Maybe I should change BIGGEST_ALIGNMENT and MALLOC_ABI_ALIGNMENT to match the malloc implementation?
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #36 from Jonathan Wakely --- Interesting. Yes, definitely similar ideas. It looks like it was solved differently though, as config/pa/pa.h has #define MALLOC_ABI_ALIGNMENT (TARGET_64BIT ? 128 : 64) which should get used by the aligned new code, even without my suggested change in PR 90569. As an aside, the comment on MALLOC_ABI_ALIGNMENT says "The glibc implementation currently provides 8-byte alignment." But glibc malloc was changed to 16-byte alignment a couple of years ago.
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #35 from dave.anglin at bell dot net --- On 2019-05-22 11:03 a.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 > > --- Comment #34 from Jonathan Wakely --- > (In reply to Jonathan Wakely from comment #33) >> The correct fix is to adjust the value of __STDCPP_DEFAULT_NEW_ALIGNMENT__ >> on targets where malloc doesn't agree with GCC's alignof(max_align_t). > That only helps for C++17 and later though :-( > > The header is defined for C++14. > Reminds me of this patch: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00528.html
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #34 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #33) > The correct fix is to adjust the value of __STDCPP_DEFAULT_NEW_ALIGNMENT__ > on targets where malloc doesn't agree with GCC's alignof(max_align_t). That only helps for C++17 and later though :-( The header is defined for C++14.
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #33 from Jonathan Wakely ---
I've been working on this again, and I think that the resource_adaptor type is
the wrong place to fix the malloc alignment problem.
The correct fix is to adjust the value of __STDCPP_DEFAULT_NEW_ALIGNMENT__ on
targets where malloc doesn't agree with GCC's alignof(max_align_t). Otherwise
even if I make resource_adaptor work for those targets, this test will still
fail:
#include
#include
#include
#include
template
inline bool aligned(void* p)
{ return (reinterpret_cast(p) % alignof(T)) == 0; }
int
main()
{
using test_type = std::max_align_t; // largest fundamental alignment
std::allocator a;
for (int i = 0; i < 10; ++i)
{
test_type* p1 = a.allocate(1);
VERIFY( aligned(p1) );
test_type* p2 = a.allocate(20);
VERIFY( aligned(p2) );
a.deallocate(p1, 1);
a.deallocate(p2, 20);
}
}
If we make std::allocator work then the tests for resource_adaptor
will also work, at least on Solaris.
[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #32 from Jonathan Wakely --- *** Bug 89732 has been marked as a duplicate of this bug. ***
