[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691

--- Comment #42 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alexandre Oliva <aoliva@gcc.gnu.org>:

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.