From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id B2C003858D38; Tue, 6 Jun 2023 19:13:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B2C003858D38 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,221,1681200000"; d="scan'208";a="8030924" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 06 Jun 2023 11:13:27 -0800 IronPort-SDR: 7nxARV7soBc9L4ZKaJe9MXYLhh3kwRbaC5PgFAxN4l5vaDG/nNZ1Tdge6PKlUfbqICi/WLSvPE KSsYhDZFdEqbJ3k45SMKesX+m2aL0gr0lCatg25N3DBVM3EPoPmoJjMz7ZhS4b3MfqDTg2ckmm netiqFeIlzWk6fNYi5EQXoKA1mVPjIObRPV0KvCjchFfEjRUw1bjA/biDv1Lf+3y/zAVGjF0DN m1KV8kX8LYJ5q486n2Se94jeuEcGRXMsy1BYuoKhW+ElePU0oBLYIBGlH+EvJ+m0UDf8cd+3bk KdM= From: Thomas Schwinge To: , Subject: Support in the GCC(/C++) test suites for '-fno-exceptions' User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/28.2 (x86_64-pc-linux-gnu) Date: Tue, 6 Jun 2023 21:13:17 +0200 Message-ID: <873534qu9e.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-13.mgc.mentorg.com (139.181.222.13) 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,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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! 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 ena= bled # as unsupported. if { ![check_effective_target_exceptions_enabled] } { if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled" $te= xt] { 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 handling dis= abled, use '-fexceptions' to enable [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are n= ot 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'.) 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..?) Gr=C3=BC=C3=9Fe Thomas ----------------- 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