| Message ID | Y2uHDeXiivo401ni@tucnak |
|---|---|
| State | New |
| Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C69453858C2F for <patchwork@sourceware.org>; Wed, 9 Nov 2022 10:55:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C69453858C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1667991353; bh=0bggSWISsuqjuTmZGhWATEYGVdAOIiVk+vJOUK5BIcM=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=foc0oL3C4Ef814sV5y3tAuUOCwu9Fwz9Yw+Sf6rkxt0WmJ7vbE2j1q00s1HHtfEV5 GHf9BfJKw7rAxfg2CaP5lC2to90fuoAyc1BVd4fhVZ4mRtfM2Cedp5xVLsWZSZ25Xo G0Da1zNHEBUoML+4SG+W23Jl25PmBD3VhhtPXTA4= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 5635F38582AB for <gcc-patches@gcc.gnu.org>; Wed, 9 Nov 2022 10:55:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5635F38582AB Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-20-BjPbe1qzOn-Ii5xgYwVTrA-1; Wed, 09 Nov 2022 05:55:13 -0500 X-MC-Unique: BjPbe1qzOn-Ii5xgYwVTrA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9A533185A7AC for <gcc-patches@gcc.gnu.org>; Wed, 9 Nov 2022 10:55:13 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5B10640C6EC3; Wed, 9 Nov 2022 10:55:13 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2A9AtAkc4104848 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 9 Nov 2022 11:55:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2A9AtA2c4104847; Wed, 9 Nov 2022 11:55:10 +0100 Date: Wed, 9 Nov 2022 11:55:09 +0100 To: Aldy Hernandez <aldyh@redhat.com> Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix up foperator_abs::op1_range [PR107569] Message-ID: <Y2uHDeXiivo401ni@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jakub Jelinek <jakub@redhat.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
| Series |
Fix up foperator_abs::op1_range [PR107569]
|
|
Commit Message
Jakub Jelinek
Nov. 9, 2022, 10:55 a.m. UTC
Hi! foperator_abs::op1_range works except for the NaN handling, from: [frange] double [-Inf, 1.79769313486231570814527423731704356798070567525844996599e+308 (0x0.fffffffffffff8p+1024)] lhs it computes r [frange] double [-1.79769313486231570814527423731704356798070567525844996599e+308 (-0x0.fffffffffffff8p+1024), 1.79769313486231570814527423731704356798070567525844996599e+308 (0x0.fffffffffffff8p+1024)] +-NAN which is correct except for the +-NAN part. For r before the final step it makes sure to add -NAN if there is +NAN in the lhs range, but the final r.union_ makes it unconditional +-NAN, because the frange ctor sets +-NAN. So, I think we need to clear it (or have some set variant which says not to set NAN). This patch fixes that, but isn't enough to fix the PR, something in the assumptions handling is still broken (and the PR has other parts). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-11-09 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/107569 * range-op-float.cc (foperator_abs::op1_range): Clear NaNs from the negatives frange before unioning it into r. Jakub
Comments
On Wed, Nov 9, 2022 at 11:55 AM Jakub Jelinek <jakub@redhat.com> wrote: > > Hi! > > foperator_abs::op1_range works except for the NaN handling, > from: > [frange] double [-Inf, 1.79769313486231570814527423731704356798070567525844996599e+308 (0x0.fffffffffffff8p+1024)] > lhs it computes r > [frange] double [-1.79769313486231570814527423731704356798070567525844996599e+308 (-0x0.fffffffffffff8p+1024), 1.79769313486231570814527423731704356798070567525844996599e+308 (0x0.fffffffffffff8p+1024)] +-NAN > which is correct except for the +-NAN part. > For r before the final step it makes sure to add -NAN if there is +NAN > in the lhs range, but the final r.union_ makes it unconditional +-NAN, > because the frange ctor sets +-NAN. > So, I think we need to clear it (or have some set variant which > says not to set NAN). > > This patch fixes that, but isn't enough to fix the PR, something in > the assumptions handling is still broken (and the PR has other parts). LGTM. Sorry I haven't gotten to the PR yet. I'll poke at it later today. Thanks. Aldy > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2022-11-09 Jakub Jelinek <jakub@redhat.com> > > PR tree-optimization/107569 > * range-op-float.cc (foperator_abs::op1_range): Clear NaNs > from the negatives frange before unioning it into r. > > --- gcc/range-op-float.cc.jj 2022-11-06 11:56:27.138137781 +0100 > +++ gcc/range-op-float.cc 2022-11-08 18:13:18.026974667 +0100 > @@ -1280,9 +1280,10 @@ foperator_abs::op1_range (frange &r, tre > return true; > // Then add the negative of each pair: > // ABS(op1) = [5,20] would yield op1 => [-20,-5][5,20]. > - r.union_ (frange (type, > - real_value_negate (&positives.upper_bound ()), > - real_value_negate (&positives.lower_bound ()))); > + frange negatives (type, real_value_negate (&positives.upper_bound ()), > + real_value_negate (&positives.lower_bound ())); > + negatives.clear_nan (); > + r.union_ (negatives); > return true; > } > > > Jakub >
--- gcc/range-op-float.cc.jj 2022-11-06 11:56:27.138137781 +0100 +++ gcc/range-op-float.cc 2022-11-08 18:13:18.026974667 +0100 @@ -1280,9 +1280,10 @@ foperator_abs::op1_range (frange &r, tre return true; // Then add the negative of each pair: // ABS(op1) = [5,20] would yield op1 => [-20,-5][5,20]. - r.union_ (frange (type, - real_value_negate (&positives.upper_bound ()), - real_value_negate (&positives.lower_bound ()))); + frange negatives (type, real_value_negate (&positives.upper_bound ()), + real_value_negate (&positives.lower_bound ())); + negatives.clear_nan (); + r.union_ (negatives); return true; }