From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 776943857B9B for ; Wed, 7 Jun 2023 08:12:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 776943857B9B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686125569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=chPWHE21wJCL0g8EUSQz80ypDAvT+zplkO8100BYNPc=; b=bJ0AUTT9ysJTZa4ThBj5Bpjl0myV4zJhrNk1OLwBkm/WL2YaShiseDPPKtF0EbzoBsBL4R ZTvXo5VNNVlUxMLTTcZ+Nd7x4CvJrUfApVR5DqND6prtFdApEQKrSIKfBmTHeyOQ2dgbF2 98CVFMP5hdcGkd4X1LagQ4Tcmm86rAE= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-R1jVSU7YMKWJWlDAVz9LXw-1; Wed, 07 Jun 2023 04:12:46 -0400 X-MC-Unique: R1jVSU7YMKWJWlDAVz9LXw-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2b1d8fa4629so20377271fa.0 for ; Wed, 07 Jun 2023 01:12:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686125563; x=1688717563; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=chPWHE21wJCL0g8EUSQz80ypDAvT+zplkO8100BYNPc=; b=fyDF2GTapkzlwYvg20yFrmTTaXIFafWMakxY2uv422URbiH541dMthvYMWS9etGHs0 +OU9bBdXzNQXGW2M5h6+ecjtstdaLnjgrOZj+OI03sI7H4yMaMl3Oc32KzF/0Tu3J0ap eMy3RfI+/JzJNxUQrwZ3JNsh90PeDCGVBUj9XnjLX7siGziEClfuznzUAagPdrnMPhlK Ox2SYJ3LWdDMhIa/225LpvtaoI9VzHILOKxtTdiGA2M+aA1dIrubn9TTJZluQw92M7lK BcmODXYkZ57DihQOmqoW03sKvobnhkAvGzG48n+zI5SNO7td37RDAGlU3AMsz5QNMJFH UU2Q== X-Gm-Message-State: AC+VfDwtNPPcXtv8LCkHdxSFgVqI0lCU5FgTr6j+45THETIWXpV0ww0k HEdGPAydJOgv/W5KOcIsasl2L1mhEqMZ9LmTQONMuZhuWRYZRdQT5EcSXEhlGShdgAxM571JrPN 2LOG/uoEseMDLZ/aGJfwkKJwxRQNlAw5y0d2x+46mfQ== X-Received: by 2002:a2e:b008:0:b0:2b1:da62:2a86 with SMTP id y8-20020a2eb008000000b002b1da622a86mr2060291ljk.33.1686125563494; Wed, 07 Jun 2023 01:12:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4mIPR3sj0jRTdyuugIyoXlct8kfGyhni4FrnlDqeOaI68/KkIryuNl501He/723OWyAaBk927FZjfurR1ixMI= X-Received: by 2002:a2e:b008:0:b0:2b1:da62:2a86 with SMTP id y8-20020a2eb008000000b002b1da622a86mr2060240ljk.33.1686125563194; Wed, 07 Jun 2023 01:12:43 -0700 (PDT) MIME-Version: 1.0 References: <873534qu9e.fsf@euler.schwinge.homeip.net> <87y1kvpwxo.fsf@euler.schwinge.homeip.net> In-Reply-To: <87y1kvpwxo.fsf@euler.schwinge.homeip.net> From: Jonathan Wakely Date: Wed, 7 Jun 2023 09:12:31 +0100 Message-ID: Subject: Re: Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions') To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, Jozef Lawrynowicz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000003dbff205fd85b319" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000003dbff205fd85b319 Content-Type: text/plain; charset="UTF-8" On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote: > Hi! > > 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 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 > // . > > -// { 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 target instead of dg-skip-if. --0000000000003dbff205fd85b319--