Hi! 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++. [...] > Not having heard anything contrary regarding the compiler side of things, > I've now been working on that, see below. >>> 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"? Similarly, OK to push the attached "Skip a number of C++ 'g++.dg/tree-prof/' test cases for '-fno-exceptions' testing"? 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