aboutsummaryrefslogtreecommitdiff
path: root/gcc
diff options
context:
space:
mode:
authorAlexandre Oliva <oliva@adacore.com>2020-05-13 04:49:00 -0300
committerGiuliano Belinassi <giuliano.belinassi@usp.br>2020-08-17 13:03:11 -0300
commit76ff781bdec498c01dc1b32dcaacfe342de31e94 (patch)
tree0f6f4367be081c0eac28e4dcbf39f8c82953e08e /gcc
parenta115e7bc962ea894087f568bfec7702a11a22b97 (diff)
downloadgcc-76ff781bdec498c01dc1b32dcaacfe342de31e94.zip
gcc-76ff781bdec498c01dc1b32dcaacfe342de31e94.tar.gz
gcc-76ff781bdec498c01dc1b32dcaacfe342de31e94.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')
0 files changed, 0 insertions, 0 deletions