* [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
@ 2020-05-13 7:51 ` cvs-commit at gcc dot gnu.org
2020-05-26 10:15 ` cvs-commit at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-05-13 7:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
2020-05-13 7:51 ` [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs cvs-commit at gcc dot gnu.org
@ 2020-05-26 10:15 ` cvs-commit at gcc dot gnu.org
2020-10-31 21:16 ` redi at gcc dot gnu.org
` (14 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-05-26 10:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #43 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Alexandre Oliva
<aoliva@gcc.gnu.org>:
https://gcc.gnu.org/g:b425be2c4c6763436d63543501c6762ae031e43c
commit r10-8186-gb425be2c4c6763436d63543501c6762ae031e43c
Author: Alexandre Oliva <oliva@adacore.com>
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)
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
2020-05-13 7:51 ` [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs cvs-commit at gcc dot gnu.org
2020-05-26 10:15 ` cvs-commit at gcc dot gnu.org
@ 2020-10-31 21:16 ` redi at gcc dot gnu.org
2021-02-17 16:30 ` danglin at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-31 21:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #44 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-10-31 21:16 ` redi at gcc dot gnu.org
@ 2021-02-17 16:30 ` danglin at gcc dot gnu.org
2021-02-17 16:46 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: danglin at gcc dot gnu.org @ 2021-02-17 16:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #45 from John David Anglin <danglin at gcc dot gnu.org> ---
We see this fail on hppa-linux:
https://buildd.debian.org/status/fetch.php?pkg=mysql-8.0&arch=hppa&ver=8.0.23-3&stamp=1613526368&raw=0
[ 49%] Building CXX object
storage/innobase/CMakeFiles/innobase.dir/api/api0api.cc.o
cd /<<PKGBUILDDIR>>/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/<<PKGBUILDDIR>>/builddir -I/<<PKGBUILDDIR>>/builddir/include
-I/<<PKGBUILDDIR>> -I/<<PKGBUILDDIR>>/include
-I/<<PKGBUILDDIR>>/storage/innobase -I/<<PKGBUILDDIR>>/storage/innobase/include
-I/<<PKGBUILDDIR>>/storage/innobase/handler -I/<<PKGBUILDDIR>>/sql
-I/<<PKGBUILDDIR>>/sql/auth -isystem /<<PKGBUILDDIR>>/extra/rapidjson/include
-isystem /usr/include/editline -std=c++14 -fno-omit-frame-pointer -g -O2
-ffile-prefix-map=/<<PKGBUILDDIR>>=. -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
/<<PKGBUILDDIR>>/storage/innobase/api/api0api.cc
In file included from
/<<PKGBUILDDIR>>/storage/innobase/include/sync0types.h:42,
from /<<PKGBUILDDIR>>/storage/innobase/include/univ.i:588,
from /<<PKGBUILDDIR>>/storage/innobase/os/file.h:47,
from /<<PKGBUILDDIR>>/storage/innobase/include/os0file.h:47,
from /<<PKGBUILDDIR>>/storage/innobase/include/api0misc.h:40,
from /<<PKGBUILDDIR>>/storage/innobase/api/api0api.cc:41:
/<<PKGBUILDDIR>>/storage/innobase/include/ut0new.h: In instantiation of ‘class
ut_allocator<PolicyMutex<OSTrackMutex<GenericPolicy> > >’:
/<<PKGBUILDDIR>>/storage/innobase/include/ut0new.h:1033:19: required from
‘void ut_delete(T*) [with T = PolicyMutex<OSTrackMutex<GenericPolicy> >]’
/<<PKGBUILDDIR>>/storage/innobase/include/dict0mem.h:2568:5: required from
here
/<<PKGBUILDDIR>>/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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2021-02-17 16:30 ` danglin at gcc dot gnu.org
@ 2021-02-17 16:46 ` redi at gcc dot gnu.org
2021-02-17 16:58 ` dave.anglin at bell dot net
` (11 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: redi at gcc dot gnu.org @ 2021-02-17 16:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #46 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-02-17 16:46 ` redi at gcc dot gnu.org
@ 2021-02-17 16:58 ` dave.anglin at bell dot net
2021-03-25 15:13 ` seurer at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: dave.anglin at bell dot net @ 2021-02-17 16:58 UTC (permalink / raw)
To: gcc-bugs
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 <redi at gcc dot gnu.org> ---
> (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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2021-02-17 16:58 ` dave.anglin at bell dot net
@ 2021-03-25 15:13 ` seurer at gcc dot gnu.org
2021-05-14 9:48 ` [Bug libstdc++/77691] [9/10/11/12 " jakub at gcc dot gnu.org
` (9 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: seurer at gcc dot gnu.org @ 2021-03-25 15:13 UTC (permalink / raw)
To: gcc-bugs
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 passes 1
# of unexpected failures 1
/home/seurer/gcc/git/gcc-9-test/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc:125:
void test03(): Assertion 'aligned<max_align_t>(p)' failed.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [9/10/11/12 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2021-03-25 15:13 ` seurer at gcc dot gnu.org
@ 2021-05-14 9:48 ` jakub at gcc dot gnu.org
2021-06-01 8:08 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-05-14 9:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|8.5 |9.4
--- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [9/10/11/12 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2021-05-14 9:48 ` [Bug libstdc++/77691] [9/10/11/12 " jakub at gcc dot gnu.org
@ 2021-06-01 8:08 ` rguenth at gcc dot gnu.org
2022-05-27 9:36 ` [Bug libstdc++/77691] [10/11/12/13 " rguenth at gcc dot gnu.org
` (7 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-06-01 8:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|9.4 |9.5
--- Comment #50 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2021-06-01 8:08 ` rguenth at gcc dot gnu.org
@ 2022-05-27 9:36 ` rguenth at gcc dot gnu.org
2022-06-28 10:32 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-27 9:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|9.5 |10.4
--- Comment #51 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2022-05-27 9:36 ` [Bug libstdc++/77691] [10/11/12/13 " rguenth at gcc dot gnu.org
@ 2022-06-28 10:32 ` jakub at gcc dot gnu.org
2023-01-05 21:26 ` danglin at gcc dot gnu.org
` (5 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-06-28 10:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.4 |10.5
--- Comment #52 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2022-06-28 10:32 ` jakub at gcc dot gnu.org
@ 2023-01-05 21:26 ` danglin at gcc dot gnu.org
2023-01-08 23:10 ` danglin at gcc dot gnu.org
` (4 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: danglin at gcc dot gnu.org @ 2023-01-05 21:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
John David Anglin <danglin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2016-09-22 00:00:00 |2023-1-5
--- Comment #53 from John David Anglin <danglin at gcc dot gnu.org> ---
Still fails on hppa64-hp-hpux11.11.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2023-01-05 21:26 ` danglin at gcc dot gnu.org
@ 2023-01-08 23:10 ` danglin at gcc dot gnu.org
2023-01-09 11:20 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: danglin at gcc dot gnu.org @ 2023-01-08 23:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #54 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 54213
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54213&action=edit
Patch to fix test failure on hppa64-hp-hpux11.11
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2023-01-08 23:10 ` danglin at gcc dot gnu.org
@ 2023-01-09 11:20 ` redi at gcc dot gnu.org
2023-01-09 22:14 ` dave.anglin at bell dot net
` (2 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: redi at gcc dot gnu.org @ 2023-01-09 11:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #55 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 54215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54215&action=edit
Generalise special case for malloc not afreeing with max_align_t
I think we also want to fix the actual code to meet the guarantee, not just
relax the test.
Maybe like this.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2023-01-09 11:20 ` redi at gcc dot gnu.org
@ 2023-01-09 22:14 ` dave.anglin at bell dot net
2023-01-12 20:59 ` cvs-commit at gcc dot gnu.org
2023-07-07 10:31 ` [Bug libstdc++/77691] [11/12/13/14 " rguenth at gcc dot gnu.org
16 siblings, 0 replies; 17+ messages in thread
From: dave.anglin at bell dot net @ 2023-01-09 22:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #56 from dave.anglin at bell dot net ---
On 2023-01-09 6:20 a.m., redi at gcc dot gnu.org wrote:
> Maybe like this.
Actually, the change i sent was for
libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc.
It still fails. No objection to the approach.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2023-01-09 22:14 ` dave.anglin at bell dot net
@ 2023-01-12 20:59 ` cvs-commit at gcc dot gnu.org
2023-07-07 10:31 ` [Bug libstdc++/77691] [11/12/13/14 " rguenth at gcc dot gnu.org
16 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-01-12 20:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #57 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:f629f63d2d9d7ad2c43f8e451f0f6e32b5f4d06a
commit r13-5127-gf629f63d2d9d7ad2c43f8e451f0f6e32b5f4d06a
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Thu Jan 12 10:58:13 2023 +0000
libstdc++: Extend max_align_t special case to 64-bit HP-UX [PR77691]
GCC's std::max_align_t doesn't agree with the system malloc on HP-UX, so
generalize the current hack for Solaris to apply to that target too.
libstdc++-v3/ChangeLog:
PR libstdc++/77691
* include/experimental/memory_resource
(_GLIBCXX_MAX_ALIGN_MATCHES_MALLOC): Define.
(do_allocate, do_deallocate): Check it.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Relax expected behaviour for 64-bit hppa-hp-hpux11.11.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/77691] [11/12/13/14 regression] experimental/memory_resource/resource_adaptor.cc FAILs
[not found] <bug-77691-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2023-01-12 20:59 ` cvs-commit at gcc dot gnu.org
@ 2023-07-07 10:31 ` rguenth at gcc dot gnu.org
16 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-07-07 10:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.5 |11.5
--- Comment #58 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.
^ permalink raw reply [flat|nested] 17+ messages in thread