https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117713
Bug ID: 117713
Summary: [15 regression] g++.dg/simulate-thread/atomics-1.C
FAILs on 32-bit SPARC
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
Target Milestone: ---
Target: sparc*-sun-solaris2.11
Between 20241008 (8b407d5c6940a65d78a544f9c66850e619638171) and 20241009
(c0bc9a153ae6ab649e2fcc3af53ebcd37df0a871),
g++.dg/simulate-thread/atomics-1.C regressed on 32-bit SPARC:
+FAIL: g++.dg/simulate-thread/atomics-1.C -O0 -g thread simulation test
at -O0 only:
Thread 2 hit Breakpoint 1, simulate_thread_main () at
/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/simulate-thread/atomics-1.C:65
65 atomi = INT_MAX;
0x00011b54 65 atomi = INT_MAX;
[...]
0x00011db0 in std::__atomic_base<int>::store (this=0x22314 <atomi>,
__i=2147483647, __m=std::memory_order_seq_cst) at
/var/gcc/regression/master/11.4-gcc/build/sparc-sun-solaris2.11/libstdc++-v3/include/bits/atomic_base.h:473
473 = __m & __memory_order_mask;
474 __glibcxx_assert(__b != memory_order_acquire);
0x00011db8 474 __glibcxx_assert(__b != memory_order_acquire);
[...]
0x00011e7c 476 __glibcxx_assert(__b != memory_order_consume);
0x0002207c in std::__glibcxx_assert_fail(char const*, int, char const*, char
const*)@got.plt ()
0x00022080 in std::__glibcxx_assert_fail(char const*, int, char const*, char
const*)@plt ()
0x00022010 in _PROCEDURE_LINKAGE_TABLE_ ()
[...]
0xfe9a8630 in _lookup_sym () from /usr/lib/ld.so.1
where the test has deeply recursed into _lookup_sym.
It turns out this is due to
commit 361d230fd7800a7e749aba8ed020f54f5c26d504
Author: Jonathan Wakely <jwak...@redhat.com>
Date: Thu Sep 26 16:55:07 2024 +0100
libstdc++: Enable _GLIBCXX_ASSERTIONS by default for -O0 [PR112808]
I've managed to get the test to PASS again by manually compiling it with
_GLIBCXX_NO_ASSERTIONS. I wonder how best to handle this, though: do this on
SPARC && ! __OPTIMIZE__ only?
