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 30E223858D37 for ; Mon, 29 Aug 2022 13:55:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 30E223858D37 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=1661781299; 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=D6FoJRurr2UE8jNL+kcHkzm1yHnjRsX4aG0yousRykc=; b=ENW/03Hmq1PtdLnNZFaRYo2ItbXUQYnZ/BfQHwRiPCVKR37XsafUv6RQ/l58KqA4dH81t1 Qonf1LN7PJvKiZWuY2EcEj1K/jOE47syu7uWQNIE/2u6j35WTEV+XfR8qcrhdz8c9SlY9u 9gmzCza00V07A1E+Cu6KdGEAgPwebc0= 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-256-DJks1fntOmSmYAzUx_Gctw-1; Mon, 29 Aug 2022 09:54:57 -0400 X-MC-Unique: DJks1fntOmSmYAzUx_Gctw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 64FAB1C006A4; Mon, 29 Aug 2022 13:54:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F3460492CA2; Mon, 29 Aug 2022 13:54:56 +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 27TDssbL2146187 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 29 Aug 2022 15:54:54 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 27TDsraa2146186; Mon, 29 Aug 2022 15:54:53 +0200 Date: Mon, 29 Aug 2022 15:54:53 +0200 From: Jakub Jelinek To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod , Andrew Pinski Subject: Re: [PATCH] Add support for floating point endpoints to frange. Message-ID: Reply-To: Jakub Jelinek References: <20220823114224.904934-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 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=-4.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote: > For convenience, singleton_p() returns false for a NAN. IMO, it makes > the implementation cleaner, but I'm not wed to the idea if someone > objects. If singleton_p() is used to decide whether one can just replace a variable with singleton range with a constant, then certainly. If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and NaNs have lots of different representations (the sign bit is ignored except for stuff like copysign/signbit, there are qNaNs and sNaNs and except for the single case how Inf is represented, all other values of the mantissa mean different representations of NaN). So, unless we track which exact form of NaN can appear, NaN or any [x, x] range with NaN property set can't be a singleton. There could be programs that propagate something important in NaN mantissa and would be upset if frange kills that. Of course, one needs to take into account that when a FPU creates NaN, it will create the canonical qNaN. Jakub