From: Jonathan Wakely <jwakely@redhat.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: gcc@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: Support in the GCC(/C++) test suites for '-fno-exceptions'
Date: Tue, 6 Jun 2023 20:31:21 +0100 [thread overview]
Message-ID: <CACb0b4kDiwp5nEY952rbLAKy7_+iJey71z3WNMUxahTaLQt6vA@mail.gmail.com> (raw)
In-Reply-To: <873534qu9e.fsf@euler.schwinge.homeip.net>
[-- Attachment #1: Type: text/plain, Size: 4857 bytes --]
On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge <thomas@codesourcery.com>
wrote:
> 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'.)
>
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.
We already have a handful of tests that use #if __cpp_exceptions to make
those parts conditional on exception support. We also have exactly one test
that is currently UNSUPPORTED when -fno-exceptions is used:
testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:// {
dg-skip-if "" { *-*-* } { "-fno-exceptions" } }
That could be changed to use an effective target keyword instead.
To add an effective-target to the libstdc++ testsuite would be as simple as:
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1421,6 +1421,14 @@ proc check_effective_target_tzdb { } {
}]
}
+# Return 1 if exception handling is enabled.
+proc check_effective_target_exceptions_enabled { } {
+ return [check_v3_target_prop_cached et_eh {
+ set cond "defined __cpp_exceptions"
+ return [v3_check_preprocessor_condition eh $cond]
+ }]
+}
+
set additional_prunes ""
if { [info exists env(GCC_RUNTEST_PARALLELIZE_DIR)] \
However, you probably want to add it to the main testsuite instead, which
would be a little more involved (the v3_check_preprocessor_condition proc
is specific to libstdc++).
> 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..?)
>
IMHO just defining an effective target keyword and then using that in test
selectors seems simpler, and doesn't require changes to the compiler, just
the tests.
prev parent reply other threads:[~2023-06-06 19:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 19:13 Thomas Schwinge
2023-06-06 19:31 ` Jonathan Wakely [this message]
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=CACb0b4kDiwp5nEY952rbLAKy7_+iJey71z3WNMUxahTaLQt6vA@mail.gmail.com \
--to=jwakely@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
--cc=thomas@codesourcery.com \
/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).