Hi! On 2023-09-08T15:30:50+0200, I wrote: > GCC/C++ front end maintainers, please provide input on the overall > approach here: Jason verbally ACKed this at the GNU Tools Cauldron 2023. > On 2023-06-15T17:15:54+0200, I wrote: >> 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++. [...] > >> Per your and my changes a few days ago, we've already got libstdc++ >> covered, [...] > >> 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 ). Done: "Improve test suite coverage for '-fno-exceptions' configurations". >>>> 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"? > > I've re-attached my patch from a few months ago: > "Skip a number of C++ test cases for '-fno-exceptions' testing". > (I'd obviously re-check for current master branch before 'git push'.) Pushed to master branch commit fe65f4a2a39b389a4240dc59d856b082c0b5ad96 "Skip a number of C++ test cases for '-fno-exceptions' testing", see attached. Grüße Thomas > If there is interest in this at all, I'd then later complete and submit > my more or less WIP patches for the slightly more involved test case > scenarios. > > > Grüße > Thomas > > >>>> (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