Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions')
Thomas Schwinge
thomas@codesourcery.com
Wed Jun 7 07:13:07 GMT 2023
Hi!
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++.
Assuming no issues found in testing, OK to push the attached
"Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing"?
(Thanks, Jozef!)
> 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" } }
ACK -- that'll only work for explicit '-fno-exceptions', but not for
implicit (say, via 'CC1PLUS_SPEC'), right? So, indeed:
> That could be changed to use an effective target keyword instead.
I'll look into that later.
> 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]
> + }]
> +}
> +
Well, we don't even need to do that, because:
> 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++).
..., this has already been done in Subversion r279246
(Git commit a9046e9853024206bec092dd63e21e152cb5cbca)
"[MSP430] -Add fno-exceptions multilib" (thanks, Jozef!):
--- gcc/testsuite/lib/target-supports.exp
+++ gcc/testsuite/lib/target-supports.exp
@@ -8990,6 +8990,24 @@ proc check_effective_target_exceptions {} {
return 1
}
+# Used to check if the testing configuration supports exceptions.
+# Returns 0 if exceptions are unsupported or disabled (e.g. by passing
+# -fno-exceptions). Returns 1 if exceptions are enabled.
+proc check_effective_target_exceptions_enabled {} {
+ return [check_cached_effective_target exceptions_enabled {
+ if { [check_effective_target_exceptions] } {
+ return [check_no_compiler_messages exceptions_enabled assembly {
+ void foo (void)
+ {
+ throw 1;
+ }
+ }]
+ } else {
+ # If exceptions aren't supported, then they're not enabled.
+ return 0
+ }
+ }]
+}
proc check_effective_target_tiny {} {
return [check_cached_effective_target tiny {
..., and it even already has one usage in libstdc++, per your
commit 4c27c6584d0c15926f57ac40f931e238cf0b3110
"libstdc++: Make testsuite usable with -fno-exceptions":
--- libstdc++-v3/testsuite/23_containers/vector/bool/72847.cc
+++ libstdc++-v3/testsuite/23_containers/vector/bool/72847.cc
@@ -15,7 +15,7 @@
// with this library; see the file COPYING3. If not see
// <http://www.gnu.org/licenses/>.
-// { dg-skip-if "" { *-*-* } { "-fno-exceptions" } }
+// { dg-require-effective-target exceptions_enabled }
#include <vector>
#include <ext/throw_allocator.h>
;-)
Grüße
Thomas
>> 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.
-----------------
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-UNSUPPORTED-.-exception-handling-disabled-fo.patch
Type: text/x-diff
Size: 1881 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20230607/b314bac9/attachment.bin>
More information about the Libstdc++
mailing list