public inbox for libstdc++-cvs@sourceware.org help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org Subject: [gcc r11-347] x86-vxworks malloc aligns to 8 bytes like solaris Date: Wed, 13 May 2020 07:51:40 +0000 (GMT) [thread overview] Message-ID: <20200513075140.47196385DC35@sourceware.org> (raw) https://gcc.gnu.org/g:883246530f1bb10d854f455e1c3d55b93675690a commit r11-347-g883246530f1bb10d854f455e1c3d55b93675690a Author: Alexandre Oliva <oliva@adacore.com> Date: Wed May 13 04:49:00 2020 -0300 x86-vxworks malloc aligns to 8 bytes like solaris Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of returned pointers on 32-bit x86, though GCC's stddef.h defines max_align_t with 16-byte alignment for __float128. This patch enables on x86-vxworks the same memory_resource workaround used for x86-solaris. The testsuite also had a workaround, defining BAD_MAX_ALIGN_T and xfailing the test; extend those to x86-vxworks as well, and remove the check for char-aligned requested allocation to be aligned like max_align_t. With that change, the test passes on x86-vxworks; I'm guessing that's the same reason for the test not to pass on x86-solaris (and on x86_64-solaris -m32), so with the fix, I'm tentatively removing the xfail. for libstdc++-v3/ChangeLog PR libstdc++/77691 * include/experimental/memory_resource (__resource_adaptor_imp::do_allocate): Handle max_align_t on x86-vxworks as on x86-solaris. (__resource_adaptor_imp::do_deallocate): Likewise. * testsuite/experimental/memory_resource/new_delete_resource.cc: Drop xfail. (BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris. (test03): Drop max-align test for char-aligned alloc. Diff: --- libstdc++-v3/ChangeLog | 12 ++++++++++++ libstdc++-v3/include/experimental/memory_resource | 4 ++-- .../experimental/memory_resource/new_delete_resource.cc | 4 +--- 3 files changed, 15 insertions(+), 5 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 3264fd4c481..0148ded22d5 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,15 @@ +2020-05-13 Alexandre Oliva <oliva@adacore.com> + + PR libstdc++/77691 + * include/experimental/memory_resource + (__resource_adaptor_imp::do_allocate): Handle max_align_t on + x86-vxworks as on x86-solaris. + (__resource_adaptor_imp::do_deallocate): Likewise. + * testsuite/experimental/memory_resource/new_delete_resource.cc: + Drop xfail. + (BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris. + (test03): Drop max-align test for char-aligned alloc. + 2020-05-08 Ulrich Drepper <drepper@redhat.com> * include/bits/atomic_base.h (atomic_flag): Implement test member diff --git a/libstdc++-v3/include/experimental/memory_resource b/libstdc++-v3/include/experimental/memory_resource index 850a78dc9a4..1c4de70c533 100644 --- a/libstdc++-v3/include/experimental/memory_resource +++ b/libstdc++-v3/include/experimental/memory_resource @@ -413,7 +413,7 @@ 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 __VXWORKS__) && defined __i386__) if (__alignment == alignof(max_align_t)) return _M_allocate<alignof(max_align_t)>(__bytes); #endif @@ -439,7 +439,7 @@ namespace pmr { do_deallocate(void* __ptr, size_t __bytes, size_t __alignment) noexcept override { -#if ! (defined __sun__ && defined __i386__) +#if ! ((defined __sun__ || defined __VXWORKS__) && defined __i386__) if (__alignment == alignof(max_align_t)) return (void) _M_deallocate<alignof(max_align_t)>(__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 8a98954345c..65a42da3f6a 100644 --- a/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc +++ b/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc @@ -17,13 +17,12 @@ // { dg-do run { target c++14 } } // { dg-require-cstdint "" } -// { dg-xfail-run-if "PR libstdc++/77691" { { i?86-*-solaris2.* x86_64-*-solaris2.* } && ilp32 } } #include <experimental/memory_resource> #include <cstdlib> #include <testsuite_hooks.h> -#if defined __sun__ && defined __i386__ +#if (defined __sun__ || defined __VXWORKS__) && defined __i386__ // See PR libstdc++/77691 # define BAD_MAX_ALIGN_T 1 #endif @@ -128,7 +127,6 @@ test03() p = r1->allocate(2, alignof(char)); VERIFY( bytes_allocated == 2 ); - VERIFY( aligned<max_align_t>(p) ); r1->deallocate(p, 2, alignof(char)); VERIFY( bytes_allocated == 0 );
reply other threads:[~2020-05-13 7:51 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200513075140.47196385DC35@sourceware.org \ --to=aoliva@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ --cc=libstdc++-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).