From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id E59F53858C2C for ; Tue, 30 Nov 2021 09:00:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E59F53858C2C Received: by mail-ed1-x536.google.com with SMTP id x15so83569825edv.1 for ; Tue, 30 Nov 2021 01:00:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/jbo8oHlusUDOScdyQcx/p3GbVDwWomW+BgwN8TMeKY=; b=m77TCrLVseIgKW7Uh96n+4M34xR+DFZwM+id9VNxvRcDLeTASMUeSEC0o3nqhCEaq7 ojftjvQgn3V8NGyMXTBaIl6h0iK51sIlwnyf0aC0rSFRnzgUH1sfE9Th09uvP2BCsQTW p4UZASy+RfDsCHVaycV3b5CR5rT05+b7LiPEFSeXEoLfQKHqIKt1mRCR1kcBIEzT9oiN b/fgdRMxUjiOOfP6K1xMjdIAMnaz8QcvHqWXR49ZY9c31jNjSv4iNMOPCFt8k6qPuDRr HOf6rJGjA63wYqx1Mme7e5pVCL7rPGapXeMVFE+ftFB2prGHYHgDt2amcbS/JmKTiyvC io9g== X-Gm-Message-State: AOAM530ECCahHsargQFmYwKKPA+h0PMVOh9eVxyJO28cJnGNeBNhOFac MVD/Djvm3YUTBpbF7E+EUGWjKJQnhqRYXZtIClw= X-Google-Smtp-Source: ABdhPJxczz+kdvIZy820UMPWz9O9pGoND2PHHwWPwIwHV/yqqdI8N1r+cxyGUmsTpvQOH5LmU1JZyMSbhbKV9ygHzDU= X-Received: by 2002:aa7:c406:: with SMTP id j6mr83167216edq.76.1638262810969; Tue, 30 Nov 2021 01:00:10 -0800 (PST) MIME-Version: 1.0 References: <20211129140050.82907-1-aldyh@redhat.com> <48e8a1e2-940e-0dc7-999a-2f1c4f4d9b53@gmail.com> In-Reply-To: From: Richard Biener Date: Tue, 30 Nov 2021 10:00:00 +0100 Message-ID: Subject: Re: [PATCH] Remove can_throw_non_call_exceptions special case from operator_div::wi_fold. To: Aldy Hernandez Cc: Jeff Law , GCC patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 09:00:17 -0000 On Tue, Nov 30, 2021 at 9:51 AM Aldy Hernandez wrote: > > On Tue, Nov 30, 2021 at 8:37 AM Richard Biener > wrote: > > > > On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez wrote: > > > > > > On Mon, Nov 29, 2021 at 3:48 PM Richard Biener > > > wrote: > > > > > > > > On Mon, Nov 29, 2021 at 3:39 PM Jeff Law wrote: > > > > > > > > > > > > > > > > > > > > On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > > > > > > As discussed in the PR. The code makes no difference, so whatever test > > > > > > we added this special case for has been fixed or is being papered over. > > > > > > I think we should fix any fall out upstream. > > > > > > > > > > > > [Unless Andrew can remember why we added this and it still applies.] > > > > > > > > > > > > Tested on x86-64 Linux. > > > > > > > > > > > > OK for trunk? > > > > > > > > > > > > PR 103451 > > > > > > > > > > > > gcc/ChangeLog: > > > > > > > > > > > > * range-op.cc (operator_div::wi_fold): Remove > > > > > > can_throw_non_call_exceptions special case. > > > > > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > > > * gcc.dg/pr103451.c: New test. > > > > > I'll defer to Andrew, but it seems wrong to me. The whole point is to > > > > > set the result to varying so that we don't know the result and never > > > > > remove the division which is critical for -fnon-call-exceptions. > > > > > > > > But that has nothing to do with computing the value range for > > > > the result which is only accessible when the stmt does _not_ throw ... > > > > > > > > That is, if we compute non-VARYING here and because of that > > > > remove the stmt then _that's_ the place to fix (IMO) > > > > > > Ughh, I think you're both right. > > > > > > We should fix this upstream AND we should test for the presence of the > > > division by 0 in the optimized dump. > > > > > > Of course doing both opens a can of worms. The division by zero can > > > be cleaned up by (at least) DCE, DSE, and the code sinking passes. > > > I've fixed all 3 in the attached (untested) patch. Dunno what y'all > > > want to do at this point. > > > > I think you need to add -fno-delete-dead-exceptions to the testcase. > > The sinking > > bug looks real, but just > > > > && (cfun->can_delete_dead_exceptions > > || !stmt_could_throw_p (cfun, stmt)) > > > > is needed there. That change is OK. > > Did you mean the entire patch (as attached) is OK, or just the sink part? The DCE and DSE parts are wrong and not needed. The remaining pieces are OK. Thanks, Richard. > Thanks. > Aldy