Hi! On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote: > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge > 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++. Assuming no issues found in testing, OK to push the attached "Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing"? (Thanks, Jozef!) > 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" } } ACK -- that'll only work for explicit '-fno-exceptions', but not for implicit (say, via 'CC1PLUS_SPEC'), right? So, indeed: > That could be changed to use an effective target keyword instead. I'll look into that later. > 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] > + }] > +} > + Well, we don't even need to do that, because: > 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++). ..., this has already been done in Subversion r279246 (Git commit a9046e9853024206bec092dd63e21e152cb5cbca) "[MSP430] -Add fno-exceptions multilib" (thanks, Jozef!): --- gcc/testsuite/lib/target-supports.exp +++ gcc/testsuite/lib/target-supports.exp @@ -8990,6 +8990,24 @@ proc check_effective_target_exceptions {} { return 1 } +# Used to check if the testing configuration supports exceptions. +# Returns 0 if exceptions are unsupported or disabled (e.g. by passing +# -fno-exceptions). Returns 1 if exceptions are enabled. +proc check_effective_target_exceptions_enabled {} { + return [check_cached_effective_target exceptions_enabled { + if { [check_effective_target_exceptions] } { + return [check_no_compiler_messages exceptions_enabled assembly { + void foo (void) + { + throw 1; + } + }] + } else { + # If exceptions aren't supported, then they're not enabled. + return 0 + } + }] +} proc check_effective_target_tiny {} { return [check_cached_effective_target tiny { ..., and it even already has one usage in libstdc++, per your commit 4c27c6584d0c15926f57ac40f931e238cf0b3110 "libstdc++: Make testsuite usable with -fno-exceptions": --- libstdc++-v3/testsuite/23_containers/vector/bool/72847.cc +++ libstdc++-v3/testsuite/23_containers/vector/bool/72847.cc @@ -15,7 +15,7 @@ // with this library; see the file COPYING3. If not see // . -// { dg-skip-if "" { *-*-* } { "-fno-exceptions" } } +// { dg-require-effective-target exceptions_enabled } #include #include ;-) Grüße Thomas >> 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. ----------------- 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