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 09:08:30 GMT 2023
Hi!
On 2023-06-07T09:12:31+0100, Jonathan Wakely <jwakely@redhat.com> wrote:
> On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge 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++.
>>
>> Assuming no issues found in testing, OK to push the attached
>> "Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++
>> testing"?
>> (Thanks, Jozef!)
>
> Yes please.
Pushed commit r14-1604-g5faaabef3819434d13fcbf749bd07bfc98ca7c3c
"Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing"
to master branch, as posted.
For one-week-old GCC commit 2720bbd597f56742a17119dfe80edc2ba86af255,
x86_64-pc-linux-gnu, I see no changes without '-fno-exceptions' (as
expected), and otherwise:
=== libstdc++ Summary for [-unix-]{+unix/-fno-exceptions+} ===
# of expected passes [-15044-]{+12877+}
# of unexpected failures [-5-]{+10+}
# of expected failures [-106-]{+77+}
{+# of unresolved testcases 6+}
# of unsupported tests [-747-]{+1846+}
As expected, there's a good number of (random example):
-PASS: 18_support/105387.cc (test for excess errors)
-PASS: 18_support/105387.cc execution test
+UNSUPPORTED: 18_support/105387.cc: exception handling disabled
..., plus the following:
[-PASS:-]{+FAIL:+} 23_containers/vector/capacity/constexpr.cc (test for excess errors)
[...]/libstdc++-v3/testsuite/23_containers/vector/capacity/constexpr.cc:101: error: non-constant condition for static assertion
In file included from [...]/libstdc++-v3/testsuite/23_containers/vector/capacity/constexpr.cc:6:
[...]/libstdc++-v3/testsuite/23_containers/vector/capacity/constexpr.cc:101: in 'constexpr' expansion of 'test_shrink_to_fit()'
[...]/libstdc++-v3/testsuite/util/testsuite_hooks.h:56: error: '__builtin_fprintf(stderr, ((const char*)"%s:%d: %s: Assertion \'%s\' failed.\012"), ((const char*)"[...]/libstdc++-v3/testsuite/23_containers/vector/capacity/constexpr.cc"), 92, ((const char*)"constexpr bool test_shrink_to_fit()"), ((const char*)"v.capacity() == 0"))' is not a constant expression
[...]/libstdc++-v3/testsuite/util/testsuite_hooks.h:66: note: in expansion of macro '_VERIFY_PRINT'
[...]/libstdc++-v3/testsuite/23_containers/vector/capacity/constexpr.cc:92: note: in expansion of macro 'VERIFY'
compiler exited with status 1
..., and:
PASS: 23_containers/vector/capacity/shrink_to_fit.cc (test for excess errors)
[-PASS:-]{+FAIL:+} 23_containers/vector/capacity/shrink_to_fit.cc execution test
[...]/libstdc++-v3/testsuite/23_containers/vector/capacity/shrink_to_fit.cc:33: void test01(): Assertion 'v.size() == v.capacity()' failed.
..., and:
PASS: 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc (test for excess errors)
[-PASS:-]{+FAIL:+} 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc execution test
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
..., and:
[-PASS:-]{+FAIL:+} ext/bitmap_allocator/check_allocate_max_size.cc (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} ext/bitmap_allocator/check_allocate_max_size.cc [-execution test-]{+compilation failed to produce executable+}
[...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_size.cc: In function 'int main()':
[...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_size.cc:29: error: 'check_allocate_max_size' is not a member of '__gnu_test'
[...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_size.cc:29: error: expected primary-expression before '>' token
[...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_size.cc:29: error: expected primary-expression before ')' token
..., and similarly:
[-PASS:-]{+FAIL:+} ext/malloc_allocator/check_allocate_max_size.cc (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} ext/malloc_allocator/check_allocate_max_size.cc [-execution test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} ext/mt_allocator/check_allocate_max_size.cc (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} ext/mt_allocator/check_allocate_max_size.cc [-execution test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} ext/new_allocator/check_allocate_max_size.cc (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} ext/new_allocator/check_allocate_max_size.cc [-execution test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} ext/pool_allocator/check_allocate_max_size.cc (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} ext/pool_allocator/check_allocate_max_size.cc [-execution test-]{+compilation failed to produce executable+}
[-PASS:-]{+FAIL:+} ext/throw_allocator/check_allocate_max_size.cc (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} ext/throw_allocator/check_allocate_max_size.cc [-execution test-]{+compilation failed to produce executable+}
That's all! :-)
Given my limited C++ language and libstdc++ implementation skills, it's
probably more effective if you address these? But I'll of course give it
a try if you'd like me to.
Grüße
Thomas
>> > 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?
>
>
> That's 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!):
>>
>
> Nice.
>
>
>>
>> --- 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>
>>
>> ;-)
>>
>>
> Ha! I forgot all about that.
>
> I'll change the rethrow_if_nested-term.cc test to the the effective target
> instead of dg-skip-if.
-----------------
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
More information about the Libstdc++
mailing list