diff options
author | Alexandre Oliva <oliva@adacore.com> | 2020-05-13 04:49:00 -0300 |
---|---|---|
committer | Alexandre Oliva <oliva@gnu.org> | 2020-05-13 04:49:00 -0300 |
commit | 883246530f1bb10d854f455e1c3d55b93675690a (patch) | |
tree | 26d92ca5ba334c1ef7a3e22a1b94aac1586ecd2c /gcc/fortran/trans-openmp.c | |
parent | a7b7818f3dbd14cc7577d25dcebaded07395c476 (diff) | |
download | gcc-883246530f1bb10d854f455e1c3d55b93675690a.zip gcc-883246530f1bb10d854f455e1c3d55b93675690a.tar.gz gcc-883246530f1bb10d854f455e1c3d55b93675690a.tar.bz2 |
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.
Diffstat (limited to 'gcc/fortran/trans-openmp.c')
0 files changed, 0 insertions, 0 deletions