Support in the GCC(/C++) test suites for '-fno-exceptions'

Support in the GCC(/C++) test suites for '-fno-exceptions'

[Thomas Schwinge]

Hi!

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'.)

For a start, the libstdc++ test suite needs
'UNSUPPORTED: [...]: exception handling disabled' enabled/ported.  (I'll
do that.)  Otherwise, a number of test cases need DejaGnu directives
conditionalized on 'target exceptions_enabled'.  (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..?)


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

Re: Support in the GCC(/C++) test suites for '-fno-exceptions'

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 4857 bytes --]

On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge <thomas@codesourcery.com>
wrote:

> Hi!
>
> 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.

We already have a handful of tests that use #if __cpp_exceptions to make
those parts conditional on exception support. We also have exactly one test
that is currently UNSUPPORTED when -fno-exceptions is used:
testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:// {
dg-skip-if "" { *-*-* } { "-fno-exceptions" } }

That could be changed to use an effective target keyword instead.

To add an effective-target to the libstdc++ testsuite would be as simple as:

--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1421,6 +1421,14 @@ proc check_effective_target_tzdb { } {
    }]
}

+# Return 1 if exception handling is enabled.
+proc check_effective_target_exceptions_enabled { } {
+    return [check_v3_target_prop_cached et_eh {
+       set cond "defined __cpp_exceptions"
+       return [v3_check_preprocessor_condition eh $cond]
+    }]
+}
+
set additional_prunes ""

if { [info exists env(GCC_RUNTEST_PARALLELIZE_DIR)] \

However, you probably want to add it to the main testsuite instead, which
would be a little more involved (the v3_check_preprocessor_condition proc
is specific to libstdc++).



> For a start, the libstdc++ test suite needs
> 'UNSUPPORTED: [...]: exception handling disabled' enabled/ported.  (I'll
> do that.)  Otherwise, a number of test cases need DejaGnu directives
> conditionalized on 'target exceptions_enabled'.  (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 defining an effective target keyword and then using that in test
selectors seems simpler, and doesn't require changes to the compiler, just
the tests.