[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #48 from seurer at gcc dot gnu.org ---
Just an FYI: the patch done for gcc 10 (trunk at the time I believe) fixed a
32-bit failure in experimental/memory_resource/new_delete_resource.cc on
powerpc64 32 bit testing. The failure still occurs with gcc 9.
make -k check RUNTESTFLAGS="--target_board=unix'{-m32}'
conformance.exp=experimental/memory_resource/new_delete_resource.cc"
FAIL: experimental/memory_resource/new_delete_resource.cc execution test
# of expected passes1
# of unexpected failures1
/home/seurer/gcc/git/gcc-9-test/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc:125:
void test03(): Assertion 'aligned(p)' failed.
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #47 from dave.anglin at bell dot net --- On 2021-02-17 11:46 a.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 > > --- Comment #46 from Jonathan Wakely --- > (In reply to John David Anglin from comment #45) >> It seems we have 8-byte alignment specified using std::max_align_t and >> 16-byte >> alignment for pthread mutexes and malloc. > That's not a libstdc++ issue though. std::max_align_t isn't defined by > libstdc++, it comes from GCC's stddef.h Thanks, looking at it.
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #46 from Jonathan Wakely --- (In reply to John David Anglin from comment #45) > It seems we have 8-byte alignment specified using std::max_align_t and > 16-byte > alignment for pthread mutexes and malloc. That's not a libstdc++ issue though. std::max_align_t isn't defined by libstdc++, it comes from GCC's stddef.h
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #45 from John David Anglin --- We see this fail on hppa-linux: https://buildd.debian.org/status/fetch.php?pkg=mysql-8.0=hppa=8.0.23-3=1613526368=0 [ 49%] Building CXX object storage/innobase/CMakeFiles/innobase.dir/api/api0api.cc.o cd /<>/builddir/storage/innobase && /usr/bin/hppa-linux-gnu-g++ -DBOOST_GEOMETRY_SQRT_CHECK_FINITENESS -DCOMPILER_HINTS -DHAVE_CONFIG_H -DHAVE_FALLOC_FL_ZERO_RANGE=1 -DHAVE_FALLOC_PUNCH_HOLE_AND_KEEP_SIZE=1 -DHAVE_IB_GCC_ATOMIC_THREAD_FENCE=1 -DHAVE_IB_GCC_SYNC_SYNCHRONISE=1 -DHAVE_IB_LINUX_FUTEX=1 -DHAVE_LZ4=1 -DHAVE_NANOSLEEP=1 -DHAVE_SCHED_GETCPU=1 -DHAVE_TLSv13 -DLINUX_NATIVE_AIO=1 -DLOG_SUBSYSTEM_TAG=\"InnoDB\" -DLZ4_DISABLE_DEPRECATE_WARNINGS -DMUTEX_EVENT -DMYSQL_SERVER -DPFS_DIRECT_CALL -DRAPIDJSON_NO_SIZETYPEDEFINE -DRAPIDJSON_SCHEMA_USE_INTERNALREGEX=0 -DRAPIDJSON_SCHEMA_USE_STDREGEX=1 -DUNIV_LINUX -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_USE_MATH_DEFINES -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/<>/builddir -I/<>/builddir/include -I/<> -I/<>/include -I/<>/storage/innobase -I/<>/storage/innobase/include -I/<>/storage/innobase/handler -I/<>/sql -I/<>/sql/auth -isystem /<>/extra/rapidjson/include -isystem /usr/include/editline -std=c++14 -fno-omit-frame-pointer -g -O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security -Wall -Wextra -Wformat-security -Wvla -Wundef -Woverloaded-virtual -Wcast-qual -Wimplicit-fallthrough=2 -Wstringop-truncation -Wsuggest-override -Wlogical-op -Wno-unused-parameter -Wno-cast-qual -DDBUG_OFF -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -o CMakeFiles/innobase.dir/api/api0api.cc.o -c /<>/storage/innobase/api/api0api.cc In file included from /<>/storage/innobase/include/sync0types.h:42, from /<>/storage/innobase/include/univ.i:588, from /<>/storage/innobase/os/file.h:47, from /<>/storage/innobase/include/os0file.h:47, from /<>/storage/innobase/include/api0misc.h:40, from /<>/storage/innobase/api/api0api.cc:41: /<>/storage/innobase/include/ut0new.h: In instantiation of ‘class ut_allocator > >’: /<>/storage/innobase/include/ut0new.h:1033:19: required from ‘void ut_delete(T*) [with T = PolicyMutex >]’ /<>/storage/innobase/include/dict0mem.h:2568:5: required from here /<>/storage/innobase/include/ut0new.h:583:28: error: static assertion failed: ut_allocator does not support over-aligned types. Use aligned_memory or another similar allocator for this type. 583 | static_assert(alignof(T) <= alignof(std::max_align_t), | ~~~^~~~ make[4]: *** [storage/innobase/CMakeFiles/innobase.dir/build.make:85: storage/innobase/CMakeFiles/innobase.dir/api/api0api.cc.o] Error 1 It seems we have 8-byte alignment specified using std::max_align_t and 16-byte alignment for pthread mutexes and malloc.
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #44 from Jonathan Wakely --- It looks like mingw* has the same problem: https://sourceforge.net/p/mingw-w64/bugs/778/ mlloc returns memory aligned to 8 bytes, GCC's stddef.h says 16 is a fundamental alignment. Even worse, mingw's own stddef.h says 8, and which definition of max_align_t you get depends on include order.
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #43 from CVS Commits --- The releases/gcc-10 branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:b425be2c4c6763436d63543501c6762ae031e43c commit r10-8186-gb425be2c4c6763436d63543501c6762ae031e43c Author: Alexandre Oliva Date: Wed May 13 05:21:42 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. (cherry picked from commit 883246530f1bb10d854f455e1c3d55b93675690a)
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #42 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:883246530f1bb10d854f455e1c3d55b93675690a commit r11-347-g883246530f1bb10d854f455e1c3d55b93675690a Author: Alexandre Oliva 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.
