diff mbox series

Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions')

Message ID 87y1kvpwxo.fsf@euler.schwinge.homeip.net
State Committed
Headers
Series Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions') |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm fail Patch failed to apply
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 fail Patch failed to apply
linaro-tcwg-bot/tcwg_gcc_check--master-arm fail Patch failed to apply

Commit Message

Thomas Schwinge June 7, 2023, 7:13 a.m. UTC 
  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

Jonathan Wakely June 7, 2023, 8:12 a.m. UTC | #1 
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.
Thomas Schwinge June 7, 2023, 9:08 a.m. UTC | #2 
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
Jonathan Wakely June 7, 2023, 11:51 a.m. UTC | #3 
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.
Jonathan Wakely June 7, 2023, 3:56 p.m. UTC | #4 
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.
diff mbox series

Patch

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(+)

diff --git a/libstdc++-v3/testsuite/lib/prune.exp b/libstdc++-v3/testsuite/lib/prune.exp
index 2d2349e7cba..be6d16c26e5 100644
--- a/libstdc++-v3/testsuite/lib/prune.exp
+++ b/libstdc++-v3/testsuite/lib/prune.exp
@@ -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