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 3EA893858D35 for ; Wed, 9 Nov 2022 11:32:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3EA893858D35 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=1667993551; 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=NrgvyiK/ravjLrBlK6zHMyLT4kXEL5lTHLYcSnRWAM0=; b=gF59WFHSknSOlmoRzpLd5AcNUP/T8+l1Wva3AN6eWorhRr9z7v+fbyxVdzXP9ZR6xgyb0o 94wiK6hydt9hhOKGoZr+6w8bh5Zf068yRzh+zYYiraELHG2N4vQt6/+tzH3cJ9YnYRwT72 Sz1G755ikrcT8O9i3Hq7vamOjAuMPrU= Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-131-7zOewUqcNH647955XUIaQg-1; Wed, 09 Nov 2022 06:32:30 -0500 X-MC-Unique: 7zOewUqcNH647955XUIaQg-1 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-36810cfa61fso159575647b3.6 for ; Wed, 09 Nov 2022 03:32:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=NrgvyiK/ravjLrBlK6zHMyLT4kXEL5lTHLYcSnRWAM0=; b=xMcpp4yqjTDWmJs9ESggWPiEhQq5L+LTFywYKz0ILUr8SqqjNQ8esZe/omhTbxd2yF Oa0UVPfZUDWKNNgWv9ViwmFJJd1JGgQx9WEEUFsuwRVtd7SfwLTM/M4zTkHwPoNtFa4r a4uUi7m+ZNDNE447b3yapHBtookN7+S8JMCunYF9An2yWTTRRHyFcqEwsLZ1+1gt7cnU 77SfA880zDaqHdhz5jKAujZBSwCTEPoIFIx8Khs1I6zYwZPQAUW0zg6/b6SiUA14kzld KfWU4z+mKVHV+0FAwPbWTWgxmY9crc/y+KZKnbrU0hTFidS4bZMJiPU8w/Dpkv0fQPxg LN9A== X-Gm-Message-State: ACrzQf0r64iov/CO/NKx4V31JXnrvLl0Ufu56T9LLx56Gc9WXW7yWeg1 VYtZzMnrHNhe/qtEiuk1YW2AJ8vCYyIshb0f8CyCj9qcks5gjqK5IXVp3vN29366hjJ865Sb7OY VEax8MNwSodOZnxjI3ZrLobCkK1W6xdw4lQ== X-Received: by 2002:a25:aa48:0:b0:6cc:57f3:4a with SMTP id s66-20020a25aa48000000b006cc57f3004amr53076060ybi.109.1667993550238; Wed, 09 Nov 2022 03:32:30 -0800 (PST) X-Google-Smtp-Source: AMsMyM52gh/DtNZ31RHFy73bn7Y+24AcSB04YWXBsbOLPumyvSt62gtNZuuv1Q9QHGbLUaZ28r4Rvasgehwj78nyYKc= X-Received: by 2002:a25:aa48:0:b0:6cc:57f3:4a with SMTP id s66-20020a25aa48000000b006cc57f3004amr53076051ybi.109.1667993549984; Wed, 09 Nov 2022 03:32:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aldy Hernandez Date: Wed, 9 Nov 2022 12:32:18 +0100 Message-ID: Subject: Re: [PATCH] Fix up foperator_abs::op1_range [PR107569] To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 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 List-Id: On Wed, Nov 9, 2022 at 11:55 AM Jakub Jelinek 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 > > 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 >