On Wed, 7 Jun 2023 at 12:51, Jonathan Wakely <jwak...@redhat.com> wrote:
>
>
> On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge <tho...@codesourcery.com>
> wrote:
>
>> Hi!
>>
>> On 2023-06-07T09:12:31+0100, Jonathan Wakely <jwak...@redhat.com> wrote:
>> > On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>> >> On 2023-06-06T20:31:21+0100, Jonathan Wakely <jwak...@redhat.com>
>> wrote:
>> >> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge <
>> tho...@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.
