Hi!

GCC/C++ front end maintainers, please provide input on the overall
approach here:

On 2023-06-15T17:15:54+0200, I wrote:
> On 2023-06-06T20:31:21+0100, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge <thomas@codesourcery.com> 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 <https://gcc.gnu.org/wiki/EasyHacks>).
>
>>> 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'.)

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