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.133.124]) by sourceware.org (Postfix) with ESMTPS id 484CD3858C5F for ; Tue, 6 Jun 2023 19:31:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 484CD3858C5F 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=1686079898; 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=tL2NqXr8Rqm//ukfeXYYZbpb3xnXYWtT+a/kWHDt+zQ=; b=cK9QpFjtLNkyWsYHCoco8bt+XToRFfY5CIQr0graupoZI5ZTHymYeBIYOYuWm1rQgMZf7S M2V8vVHHQpVjpaL5x1WvXrP6Rq+pcMcfeW8LCAyhMDay8tVsO6emDxayLrNzM9JcRxfgZT prgwIjeY+sRiBfkycLsgAgyWka1SHPo= 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-220-b1E16EeNM-KTl9U6grktpw-1; Tue, 06 Jun 2023 15:31:35 -0400 X-MC-Unique: b1E16EeNM-KTl9U6grktpw-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2b1d8fa4629so18031361fa.0 for ; Tue, 06 Jun 2023 12:31:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686079893; x=1688671893; 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=tL2NqXr8Rqm//ukfeXYYZbpb3xnXYWtT+a/kWHDt+zQ=; b=Tsou7v7qY8o44dz/i6u7uJnQF4fl30Kej4n8w78TUooyJyu+DjPwsPoyAWeCrui7rn YynRw75CjXAucpYSLUky9ENBTfafNfMdpSaDANvCEhdXitc4Jhq7MW0bBmah79SuA1aC 18ba0rUeF1qj9ugxF1W/NYS2ERKXnPlRUY0OxvOHYYJRj0B8BEpHdZHmXyptTQMJtN2t RSRg0yojQHLwccrnYdAKbzxkbpXqBP0AiPbQ4ECV8dmW/M/QwioNMZVNfAVKQJeoN5nN cF/+fMkwhXbtU3enVjlEvC0Ct7jsu31Us97RYlyHbsZUvFDtJ1clODF8sSOiFchAKVAQ Rb9g== X-Gm-Message-State: AC+VfDxqY7zMM1lbBvGNwAhmvt+VCyc2Xp+EQU5xTcAqn0Y7xDgco7yl Ah98Cq5mxeL/F8de5104SJZvsADwYJlg86m/zKclQ7h4b3qJrxDLFExw6vitHGSLJXXWKu7E/2h OzT6Z9uzJYHn3M5wHO6d+k6y6MDRFmT0= X-Received: by 2002:a2e:9655:0:b0:2af:e006:b83 with SMTP id z21-20020a2e9655000000b002afe0060b83mr1773544ljh.18.1686079893721; Tue, 06 Jun 2023 12:31:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7XDrWY8HgOSgmWATlRYFnGInCVgwoMmAnpm9A0wRf+CgArI+dDfprEH8fR98l2zm21xTWGtOk/AurINPypgdc= X-Received: by 2002:a2e:9655:0:b0:2af:e006:b83 with SMTP id z21-20020a2e9655000000b002afe0060b83mr1773536ljh.18.1686079893344; Tue, 06 Jun 2023 12:31:33 -0700 (PDT) MIME-Version: 1.0 References: <873534qu9e.fsf@euler.schwinge.homeip.net> In-Reply-To: <873534qu9e.fsf@euler.schwinge.homeip.net> From: Jonathan Wakely Date: Tue, 6 Jun 2023 20:31:21 +0100 Message-ID: Subject: Re: Support in the GCC(/C++) test suites for '-fno-exceptions' To: Thomas Schwinge Cc: gcc@gcc.gnu.org, libstdc++@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000001b284505fd7b11de" 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,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: --0000000000001b284505fd7b11de Content-Type: text/plain; charset="UTF-8" On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge wrote: > 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 > 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++. 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" } } That could be changed to use an effective target keyword instead. 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] + }] +} + set additional_prunes "" if { [info exists env(GCC_RUNTEST_PARALLELIZE_DIR)] \ 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++). > 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. --0000000000001b284505fd7b11de--