From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id E75D13858C54; Wed, 7 Jun 2023 09:08:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E75D13858C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="6.00,223,1681200000"; d="scan'208";a="9076754" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 07 Jun 2023 01:08:37 -0800 IronPort-SDR: P66xA2TOW492d8G6DYHKpUUgPtRy39yIiPnFyfV1g0+U6D/+bd7EbvMY0DFHhpZOt0KW4UnrHS J38rkxoyHvN295WLI67g5vnG8ay1gp9zgv/DE9h3kUdX90FoJKaT6gTfnqhdqpI6469hty+mlb 7n7ycrQUXUnwPdj4fqGRqqXB/h/3ePPxV+v+0mcAz7ITTJnM3yMCdfX228rnCj1DRxUXJPNopN 0WsmczIeZoKnBfWa7cqCn8gUgr3DtLbgo0LFr24pOvks/ngkq77aATPYcsnHjWokRcO7JInuk6 HJE= From: Thomas Schwinge To: Jonathan Wakely , , CC: Jozef Lawrynowicz Subject: Re: Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions') In-Reply-To: References: <873534qu9e.fsf@euler.schwinge.homeip.net> <87y1kvpwxo.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/28.2 (x86_64-pc-linux-gnu) Date: Wed, 7 Jun 2023 11:08:30 +0200 Message-ID: <87v8fzprld.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URI_HEX autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote: > On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote: >> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote: >> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge >> > wrote: >> >> This issue comes up in context of me working on C++ support for GCN a= nd >> >> 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 disable= d" >> >> $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=3D'--target_board=3Dunix/-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 handli= ng >> >> 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 disable= d' >> >> precluding other diagnostics seems to be one major issue. >> >> >> >> Is there interest in me producing the obvious (?) changes to those te= st >> >> cases, such that compiler g++ as well as target library libstdc++ tes= t >> >> results are reasonably clean? (If you think that's all "wasted effor= t", >> >> 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++ te= sting" 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: =3D=3D=3D libstdc++ Summary for [-unix-]{+unix/-fno-exc= eptions+} =3D=3D=3D # 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: '__built= in_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() =3D=3D 0"))' is not a constant expression [...]/libstdc++-v3/testsuite/util/testsuite_hooks.h:66: note: in expans= ion 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 e= rrors) [-PASS:-]{+FAIL:+} 23_containers/vector/capacity/shrink_to_fit.cc execu= tion test [...]/libstdc++-v3/testsuite/23_containers/vector/capacity/shrink_to_fi= t.cc:33: void test01(): Assertion 'v.size() =3D=3D v.capacity()' failed. ..., and: PASS: 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc (test for e= xcess errors) [-PASS:-]{+FAIL:+} 27_io/basic_ostream/inserters_arithmetic/pod/23875.c= c 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 (tes= t for excess errors) [-PASS:-]{+UNRESOLVED:+} ext/bitmap_allocator/check_allocate_max_size.c= c [-execution test-]{+compilation failed to produce executable+} [...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_si= ze.cc: In function 'int main()': [...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_si= ze.cc:29: error: 'check_allocate_max_size' is not a member of '__gnu_test' [...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_si= ze.cc:29: error: expected primary-expression before '>' token [...]/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_si= ze.cc:29: error: expected primary-expression before ')' token ..., and similarly: [-PASS:-]{+FAIL:+} ext/malloc_allocator/check_allocate_max_size.cc (tes= t for excess errors) [-PASS:-]{+UNRESOLVED:+} ext/malloc_allocator/check_allocate_max_size.c= c [-execution test-]{+compilation failed to produce executable+} [-PASS:-]{+FAIL:+} ext/mt_allocator/check_allocate_max_size.cc (test fo= r 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 f= or 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=C3=BC=C3=9Fe 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=3Dstandard)= . 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 ma= ke >> > 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 simp= le >> 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, wh= ich >> > would be a little more involved (the v3_check_preprocessor_condition p= roc >> > 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 pass= ing >> +# -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 assemb= ly >> { >> + 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 >> // . >> >> -// { dg-skip-if "" { *-*-* } { "-fno-exceptions" } } >> +// { dg-require-effective-target exceptions_enabled } >> >> #include >> #include >> >> ;-) >> >> > Ha! I forgot all about that. > > I'll change the rethrow_if_nested-term.cc test to the the effective targe= t > instead of dg-skip-if. ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955