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 A44403858C39 for ; Tue, 8 Nov 2022 11:20:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A44403858C39 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=1667906419; 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=Rq8Bpugi3p7JQFrAm9Js6kf5D71lXiB4xbs4l8+K+Xo=; b=PHiJ4Vp7ok3N2CzxQNJCJDir3bqZzJXEyI41mITpbBnSWfySWa1SNHVUvaG41LlUDyKVMw 69/biKa8fVq7OSTZsYAQ858b/+ldqC3cOaAtEhQ/dyEVcAf4O0cTVndC1UE5nFtK7jV+9i NcAD6hcsYtVhcl+kMijOa6DKj02LTNw= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-526-I359I4jmMJGIlHaHcOTwKQ-1; Tue, 08 Nov 2022 06:20:18 -0500 X-MC-Unique: I359I4jmMJGIlHaHcOTwKQ-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 E8C9D29324AE for ; Tue, 8 Nov 2022 11:20:17 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A1E0D1121314; Tue, 8 Nov 2022 11:20:17 +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 2A8BKE9a2240616 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 8 Nov 2022 12:20:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2A8BKEHD2240615; Tue, 8 Nov 2022 12:20:14 +0100 Date: Tue, 8 Nov 2022 12:20:13 +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.9 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 Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote: > As suggested upthread, I have also adjusted update_nan_sign() to drop > the NAN sign to VARYING if both operands are NAN. As an optimization > I keep the sign if both operands are NAN and have the same sign. For NaNs this still relies on something IEEE754 doesn't guarantee, as I cited, after a binary operation the sign bit of the NaN is unspecified, whether there is one NaN operand or two. It might be that all CPUs handle it the way you've implemented (that for one NaN operand the sign of NaN result will be the same as that NaN operand and for two it will be the sign of one of the two NaNs operands, never something else), but I think we'd need to check more than one implementation for that (I've only tried x86_64 and thus SSE behavior in it), so one would need to test i387 long double behavior too, ARM/AArch64, PowerPC, s390{,x}, RISCV, ... The guarantee given by IEEE754 is only for those copy, negate, abs, copySign operations, so copying values around, NEG_EXPR, ABS_EXPR, __builtin_fabs*, __builtin_copysign*. Otherwise LGTM (but would be nice to get into GCC13 not just +, but also -, *, /, sqrt at least). Jakub