Skip a number of C++ test cases for '-fno-exceptions' testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions')

[Thomas Schwinge]

Hi!

On 2023-06-06T20:31:21+0100, Jonathan Wakely <jwakely@redhat.com> wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge <thomas@codesourcery.com> wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target.  Those targets shall default to '-fno-exceptions' -- or,
>> "in other words", '-fexceptions' is not supported.  (Details omitted
>> here.)
>>
>> It did seem clear to me that with such a configuration it'll be hard to
>> get clean test results.  Then I found code in
>> 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
>>
>>     # If exceptions are disabled, mark tests expecting exceptions to be enabled
>>     # as unsupported.
>>     if { ![check_effective_target_exceptions_enabled] } {
>>         if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled" $text] {
>>             return "::unsupported::exception handling disabled"
>>         }
>>
>> ..., which, in a way, sounds as if the test suite generally is meant to
>> produce useful results for '-fno-exceptions', nice surprise!
>>
>> Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
>>
>>     RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
>>
>> ..., I find that indeed this does work for a lot of test cases, where we
>> then get (random example):
>>
>>      PASS: g++.dg/coroutines/pr99710.C  (test for errors, line 23)
>>     -PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
>>     +UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling disabled
>>
>> ..., due to:
>>
>>      [...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
>>     +[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
>> disabled, use '-fexceptions' to enable
>>      [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are
>> not permitted in handlers
>>      compiler exited with status 1
>>
>> But, we're nowhere near clean test results: PASS -> FAIL as well as
>> XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
>> precluding other diagnostics seems to be one major issue.
>>
>> Is there interest in me producing the obvious (?) changes to those test
>> cases, such that compiler g++ as well as target library libstdc++ test
>> results are reasonably clean?  (If you think that's all "wasted effort",
>> then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
>> that appear in combination with
>> 'UNSUPPORTED: [...]: exception handling disabled'.)
>
> I would welcome that for libstdc++. I do sometimes run the libstdc++ tests
> with "unusual" options, like -fno-exceptions and -fno-rtti (e.g. today I've
> been fixing FAILs that only happen with -fexcess-precision=standard). I
> just manually ignore the tests that fail for -fno-exceptions, but it would
> be great if they were automatically skipped as UNSUPPORTED.

Per your and my changes a few days ago, we've already got libstdc++
covered, with the sole exception of:

    PASS: 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc (test for excess errors)
    [-PASS:-]{+FAIL:+} 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc execution test

    terminate called after throwing an instance of 'std::bad_cast'
      what():  std::bad_cast

(Low priority for me.)

Not having heard anything contrary regarding the compiler side of things,
I've now been working on that, see below.

> We already have a handful of tests that use #if __cpp_exceptions to make
> those parts conditional on exception support.

Yes, that's an option not for all but certainly for some test cases.
(I'm not looking into that now -- but this may in fact be a good
beginner-level task, will add to <https://gcc.gnu.org/wiki/EasyHacks>).

>> Otherwise, a number of test cases need DejaGnu directives
>> conditionalized on 'target exceptions_enabled'.

Before I get to such things, even simpler: OK to push the attached
"Skip a number of C++ test cases for '-fno-exceptions' testing"?


>> (Or,
>> 'error: exception handling disabled' made a "really late" diagnostic, so
>> that it doesn't preclude other diagnostics?  I'll have a look.  Well,
>> maybe something like: in fact do not default to '-fno-exceptions', but
>> instead emit 'error: exception handling disabled' only if in a "really
>> late" pass we run into exceptions-related constructs that we cannot
>> support.  That'd also avoid PASS -> UNSUPPORTED "regressions" when
>> exception handling in fact gets optimized away, for example.  I like that
>> idea, conceptually -- but is it feasible to implement..?)
>
> IMHO just [...] using [an effective target keyword] in test
> selectors seems simpler, and doesn't require changes to the compiler, just
> the tests.

I still like the idea, but yes, I've mentally put it on file "for later"
(ha, ha, ha...) -- it doesn't seem obvious to implement.


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Skip-a-number-of-C-test-cases-for-fno-exceptions-tes.patch
Type: text/x-diff
Size: 27889 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20230615/f266ca39/attachment-0001.bin>