https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126072
Bug ID: 126072
Summary: [17 Regression] 20_util/allocator/allocate_at_least.cc
for cris-elf
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
CC: ncm at gcc dot gnu.org
Target Milestone: ---
I noticed a testsuite regression for cris-elf in the range
Last known to pass: r17-596-g90f2f90d2b5c3a
First known to fail: r17-609-g573b66baa6cb8d
FAIL: 20_util/allocator/allocate_at_least.cc -std=gnu++23 execution test
FAIL: 20_util/allocator/allocate_at_least.cc -std=gnu++26 execution test
In lib...log:
...
spawn cris-elf-run ./allocate_at_least.exe
/gcc/libstdc++-v3/testsuite/20_util/allocator/allocate_at_least.cc:129: void
extra(): Assertion 'n == __STDCPP_DEFAULT_NEW_ALIGNMENT__ / sizeof(A3)' failed.
program stopped with signal 6 (Aborted).
FAIL: 20_util/allocator/allocate_at_least.cc -std=gnu++23 execution test
Inspecting git history, it's immediately obvious that this is due to
r17-603-gacfdad706d8acc, which added that line, once again showing why it's bad
to *add* tests to an existing testfile. To wit, if it had not been added, but
put in a new file, it wouldn't count as a regression.
I believe this is due to the false assumption that
__STDCPP_DEFAULT_NEW_ALIGNMENT__ is exactly 8 (among other bad assumptions
among those tests, but this one is provably false).
Adding these lines show the actual numbers, as the test still fails on the same
line (now 132):
--- allocate_at_least.cc.orig 2026-07-01 17:29:17.371908788 +0200
+++ allocate_at_least.cc 2026-07-01 17:30:21.380518029 +0200
@@ -126,6 +126,9 @@ void extra()
}
{
auto [p, n] = SatA3::allocate_at_least(sata3, 2);
+ VERIFY(n == 2);
+ VERIFY(sizeof(A3) == 3);
+ VERIFY(__STDCPP_DEFAULT_NEW_ALIGNMENT__ == 4);
VERIFY(n == __STDCPP_DEFAULT_NEW_ALIGNMENT__ / sizeof(A3));
SatA3::deallocate(sata3, p, n);
}
cris-elf is a 32-bit target with byte alignment; always-packed alignment which
may contribute to the "surprising" setting of __STDCPP_DEFAULT_NEW_ALIGNMENT__
== 4. (I did not dig into the machinery for setting
__STDCPP_DEFAULT_NEW_ALIGNMENT__ to 4 as the number is correct.)
