Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions')
Checks
Commit Message
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
Comments
On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
> 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!)
>
Yes please.
>
> > 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.
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
On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge <thomas@codesourcery.com>
wrote:
> 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.
>
Yes, I'll fix those, thanks for the heads up.
On Wed, 7 Jun 2023 at 12:51, Jonathan Wakely <jwakely@redhat.com> wrote:
>
>
> On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge <thomas@codesourcery.com>
> wrote:
>
>> 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.
>>
>
> Yes, I'll fix those, thanks for the heads up.
>
>
Done at r14-1612-gfa8b4468e0d124
I didn't fix 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc yet
though.
From d12157a17683ff400f911751e2f2d74394f9ff5d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Wed, 7 Jun 2023 08:46:38 +0200
Subject: [PATCH] Support 'UNSUPPORTED: [...]: exception handling disabled' for
libstdc++ testing
Verbatim copy of what was added to 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune'
in Subversion r279246 (Git commit a9046e9853024206bec092dd63e21e152cb5cbca)
"[MSP430] -Add fno-exceptions multilib".
This greatly improves 'make check-target-libstdc++-v3' results for, for
example, x86_64-pc-linux-gnu with:
RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
libstdc++-v3/
* testsuite/lib/prune.exp (libstdc++-dg-prune): Support
'UNSUPPORTED: [...]: exception handling disabled'.
---
libstdc++-v3/testsuite/lib/prune.exp | 12 ++++++++++++
1 file changed, 12 insertions(+)
@@ -79,6 +79,18 @@ proc libstdc++-dg-prune { system text } {
# Ignore dsymutil warning (tool bug is actually in the linker)
regsub -all "(^|\n)\[^\n\]*could not find object file symbol for symbol\[^\n\]*" $text "" text
+ # 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"
+ }
+
+ if [regexp "(^|\n)\[^\n\]*: error: #error .__cpp_exceptions." $text] {
+ return "::unsupported::exception handling disabled"
+ }
+ }
+
foreach p $additional_prunes {
if { [string length $p] > 0 } {
# Following regexp matches a complete line containing $p.
--
2.34.1