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