On Wed, 13 Sept 2023 at 16:38, Christophe Lyon via Libstdc++ <libstd...@gcc.gnu.org> wrote: > > On Tue, 12 Sept 2023 at 11:07, Jonathan Wakely <jwak...@redhat.com> wrote: > > > On Tue, 12 Sept 2023 at 08:59, Christophe Lyon > > <christophe.l...@linaro.org> wrote: > > > I've noticed several undefined references to > > __glibcxx_backtrace_create_state too > > > 19_diagnostics/stacktrace/current.cc > > > 19_diagnostics/stacktrace/entry.cc > > > 19_diagnostics/stacktrace/stacktrace.cc > > > > Odd. These were changed in r14-3812-gb96b554592c5cb to link to > > libstdc++exp.a instead of libstdc++_libbacktrace.a, and > > __glibcxx_backtrace_create_state should be part of libstdc++exp.a now. > > If the target doesn't support libbacktrace then the symbols will be > > missing from libstdc++exp.a, but then the test should fail to match > > the effective target "stacktrace". > > > > Strange, it looks like these libs were not correctly rebuilt after I > rebased to have your patches. > I've rebuilt from scratch and these undefined references are not present > indeed.
Great! Thanks for checking. I sent a proposed patch that should remove most of the other unnecessary uses of atomics, as suggested yesterday: https://patchwork.sourceware.org/project/gcc/patch/20230913123226.2083892-1-jwak...@redhat.com/ Would you be able to check whether that improves the results further for arm4t? I think with that, you should only need the dg-require-thread-fence for the 9 or so tests under 29_atomics/ which really do require atomic synchronization.
