[PUSHED] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'

[Thomas Schwinge]

Hi Jonathan!

On 2025-03-06T19:58:55+0000, Jonathan Wakely <jwakely@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 <jwakely@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