Hi Jonathan! On 2025-03-06T19:58:55+0000, Jonathan Wakely <jwak...@redhat.com> wrote: > On Thu, 6 Mar 2025 at 19:48, Jonathan Wakely wrote: >> On Thu, 6 Mar 2025 at 14:28, Thomas Schwinge wrote: >> > In a '-fno-exceptions' configuration: >> > >> > In file included from >> > ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29: >> > [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void >> > std::__throw_format_error(const char*)’: >> > [...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: >> > unused parameter ‘__what’ [-Werror=unused-parameter] >> > 200 | __throw_format_error(const char* __what) >> > | ~~~~~~~~~~~~^~~~~~ >> > >> > libstdc++-v3/ >> > * include/bits/c++config [!__cpp_exceptions] >> > (_GLIBCXX_THROW_OR_ABORT): Reference '_EXC'. >> > >> > Co-authored-by: Jonathan Wakely <jwak...@redhat.com> >> >> Hmm, I didn't like this change (my original review said "I don't think >> we want/need this at all, but it could be done like this...")
We need something to this effect to prevent target libstdc++ build failure with '--enable-werror' in combination with '-fno-exceptions'. >> and it >> turns out that it causes diagnostic regressions. I had done a before vs. after comparison for powerpc64le-linux-gnu 'check-gcc-c++ check-target-libstdc++-v3' with 'RUNTESTFLAGS=--target_board=unix/-fno-exceptions', and not observed any difference at all. Should I regularly be doing any further testing; where are you seeing these regressions? >> The problem is in the >> front-end so I've filed it as https://gcc.gnu.org/PR119149 > > Which seems to be a dup of my own much older https://gcc.gnu.org/PR91388 > >> I think we can live with the diagnostic regressions, since it's only >> for code that's ill-formed anyway, and only for -fno-exceptions. Please let me know if there's anything I should do. Or, would these regressions be addressed by my original patch, à la: -# define _GLIBCXX_THROW_OR_ABORT(_EXC) (__builtin_abort(), (void)(_EXC)) +# define _GLIBCXX_THROW_OR_ABORT(_EXC) ((void)(_EXC), __builtin_abort()) ..., and relying on the compiler to optimize out any dead code before '__builtin_abort()'? Grüße Thomas
