public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: <gcc@gcc.gnu.org>, <libstdc++@gcc.gnu.org>
Subject: Support in the GCC(/C++) test suites for '-fno-exceptions'
Date: Tue, 6 Jun 2023 21:13:17 +0200	[thread overview]
Message-ID: <873534qu9e.fsf@euler.schwinge.homeip.net> (raw)

Hi!

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

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


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

             reply	other threads:[~2023-06-06 19:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-06 19:13 Thomas Schwinge [this message]
2023-06-06 19:31 ` Jonathan Wakely
2023-06-07  7:13   ` Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions') Thomas Schwinge
2023-06-07  8:12     ` Jonathan Wakely
2023-06-07  9:08       ` Thomas Schwinge
2023-06-07 11:51         ` Jonathan Wakely
2023-06-07 15:56           ` Jonathan Wakely
2023-06-15 15:15   ` Skip a number of C++ test cases for '-fno-exceptions' " Thomas Schwinge
2023-09-08 13:30     ` Thomas Schwinge
2023-11-03 11:03       ` Thomas Schwinge
2023-11-03 11:15         ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873534qu9e.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).