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 907F83858297 for ; Tue, 20 Sep 2022 15:10:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 907F83858297 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=1663686632; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I1Ti1GE9y/8LyNwbswOAUrv+pfGovC5dleAJB5A+qC8=; b=A/+LsyoCvaKOIfj1lSHar5s+6LFX+dJfgxC+MU0nM2TDAT0Een04alwN2CkS8dlwzr+S5C jkmbpVOuDtMDRQ95rhozQlXm+DITJJHYb6hMpB2q1kVHbtCbCL2Nzr1J6p9k21pJSuPVU6 cRih0J+G4lXQOloBoViWAoZN3w/48hk= 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-614-luCCxMMMOh-6p2wKRxGNUg-1; Tue, 20 Sep 2022 11:10:28 -0400 X-MC-Unique: luCCxMMMOh-6p2wKRxGNUg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8E77618E0046; Tue, 20 Sep 2022 15:10:28 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3340740C2064; Tue, 20 Sep 2022 15:10:28 +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 28KFA70d693444 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 20 Sep 2022 17:10:08 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28KFA1Pu693443; Tue, 20 Sep 2022 17:10:01 +0200 Date: Tue, 20 Sep 2022 17:09:56 +0200 From: Jakub Jelinek To: Aldy Hernandez Cc: Michael Matz , Richard Biener , GCC patches Subject: Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN. Message-ID: Reply-To: Jakub Jelinek References: <20220919075901.1798294-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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 Tue, Sep 20, 2022 at 04:58:38PM +0200, Aldy Hernandez wrote: > > > > deal with NaNs just fine and is required to correctly capture the sign of > > > > 'x'. If frange::set_nonnegative is supposed to be used in such contexts > > > > (and I think it's a good idea if that were the case), then set_nonnegative > > > > does _not_ imply no-NaN. > > > > > > > > In particular I would assume that, given an VAYRING frange FR, that > > > > FR.set_nonnegative() would result in an frange {[+0.0,+inf],+nan} . > > > > > > That was my understanding as well, and what my original patch did. > > > But again, I'm just the messenger. > > > > Ah, I obviously haven't followed the thread carefully then. If that's > > what it was doing then IMO it was the right thing. > > This brings me back to my original patch :). > > Richard, do you agree nonnegative should be [0.0, +INF] U +NAN. I agree with that. And similarly if there is negative that does the opposite [-INF, -0.0] U -NAN. Though, in most other places when we see that something may be a NaN, I think we need to set both +NAN and -NAN, because at least the 2008 version of IEEE 754 says: "When either an input or result is NaN, this standard does not interpret the sign of a NaN. Note, however, that operations on bit strings — copy, negate, abs, copySign — specify the sign bit of a NaN result, sometimes based upon the sign bit of a NaN operand. The logical predicate totalOrder is also affected by the sign bit of a NaN operand. For all other operations, this standard does not specify the sign bit of a NaN result, even when there is only one input NaN, or when the NaN is produced from an invalid operation." So not sure if we should count on what NaN sign bit we get normally and what we get for canonical NaN. If we could rely on it, then the rule is that if at least one input to binary operation is NaN, then that NaN is copied to result, but if both are NaNs, which one is picked isn't specified, so we might need just union the +NAN and -NAN bits from the operands. But there are still sNaNs and those ought to be turned into some qNaN and dunno if that can change the NaN bit (say turn the sNaN into canonical qNaN). If neither operand is NaN, but result is NaN because of invalid operation (0/0, inf-inf, inf+-inf, sqrt (-1) and the like), the result is qNaN, but dunno if we can rely that it will be one with positive sign. Jakub