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 599DE3858D39 for ; Tue, 8 Nov 2022 13:25:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 599DE3858D39 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=1667913900; 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:in-reply-to:in-reply-to: references:references; bh=O2kpF8nlOGoFIJr3LaLPklxBJN+mAoxAmq6OZ/sZSro=; b=MmC5D4Hj7JQUqv+mouQsW7CmamhpFAh89HtMGRe/+W48a1zcFqRS1tFjNKAl/K4ZVK0wIV ndc7Sd/P19GCPnJtvEmgDF4IQUWSHKqq9aFyGB2PHdGZ9S0ATv/walP9mwof+1biLTy2k8 61sLxNNIHBF0ceFjRAjios203uuFZ6E= 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-546-jT5ExNOuNDKiif_Tu5q4Lw-1; Tue, 08 Nov 2022 08:24:58 -0500 X-MC-Unique: jT5ExNOuNDKiif_Tu5q4Lw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AB3AB8001B8 for ; Tue, 8 Nov 2022 13:24:58 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6B6F4112132D; Tue, 8 Nov 2022 13:24:58 +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 2A8DOtM12242878 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 8 Nov 2022 14:24:56 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2A8DOoBi2242876; Tue, 8 Nov 2022 14:24:50 +0100 Date: Tue, 8 Nov 2022 14:24:50 +0100 From: Jakub Jelinek To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod Subject: Re: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats. Message-ID: Reply-To: Jakub Jelinek References: <20221013123649.474497-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 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 List-Id: On Tue, Nov 08, 2022 at 02:06:58PM +0100, Aldy Hernandez wrote: > + gcc_checking_assert (!r.nan_signbit_p (sign1)); > + if (op1_nan && op2_nan) > + { > + // If boths signs agree, we could use that sign, but IEEE754 > + // does not guarantee this for a binary operator. The x86_64 > + // architure does keep the common known sign, but further tests > + // are needed to see if other architectures do the same (i387 > + // long double, ARM/aarch64, PowerPC, s390,{,x}, RSICV, etc). s/RSICV/RISCV/ > + // In the meantime, keep sign VARYING. > + ; > + } > + else if (op1_nan) > + { > + if (op1.nan_signbit_p (sign1)) > + r.update_nan (sign1); > + } > + else if (op2_nan) > + { > + if (op2.nan_signbit_p (sign2)) > + r.update_nan (sign2); > + } Well, these cases also aren't guaranteed for binary operator. I think a conforming implementation can say copy the NaN operand to result and toggle the sign. Or, if the operand would be a sNaN, it must turn it into a qNaN (don't remember right now if there are requirements on what it can do with the mantissa which needs to change for the sNaN -> qNaN difference at least, but whether it can just generate a canonical qNaN or needs to preserve at least some bits), but could e.g. clear or toggle the sign of the NaN as well. Whether there are any such implementations or not is a question. For the single qNaN operand case, it would surprise me if anybody bothered to tweak the sign bit in any way, just copying the input seems simpler to me, but for the sNaN -> qNaN conversion it wouldn't surprise me that much. Jakub