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 3B1833858C2F for ; Tue, 6 Sep 2022 07:59:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B1833858C2F 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=1662451157; 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=Rw1FR7uiZfXirSDVdE8m/0Z+86zbuLhxGeR8PYeb+Us=; b=YomtdbuehXrrTn6xXaUDIziVSu465jWgAp967bVxGtwN048/sWttXKm1IGEnNS/5lB+SA2 iIC34GYO1EK6ecGLIkxHJaWqMciws1SdTUOl4fq9YhqBMh9U7AMggS7iZRNjnyNDPPiJbw mlIwVIUR6AntwHjlYH1IGkBdfKUOU5Y= 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-664-ds0pGPnEMved4znC1aB-xg-1; Tue, 06 Sep 2022 03:59:16 -0400 X-MC-Unique: ds0pGPnEMved4znC1aB-xg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8703885A58A; Tue, 6 Sep 2022 07:59:16 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B906492C3B; Tue, 6 Sep 2022 07:59:16 +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 2867xD6i2016821 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 6 Sep 2022 09:59:13 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2867xCQl2016820; Tue, 6 Sep 2022 09:59:12 +0200 Date: Tue, 6 Sep 2022 09:59:12 +0200 From: Jakub Jelinek To: Aldy Hernandez Cc: GCC patches , Richard Biener , Andrew MacLeod Subject: Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc Message-ID: Reply-To: Jakub Jelinek References: <20220906072901.3472801-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 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.6 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 Tue, Sep 06, 2022 at 09:49:55AM +0200, Aldy Hernandez wrote: > On Tue, Sep 6, 2022 at 9:44 AM Jakub Jelinek wrote: > > > > On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernandez wrote: > > > if (x <= Inf) > > > > This will be [-Inf, Inf] !NAN on the true side and > > NAN (either sign) on the false side indeed. > > > > > if (x < -Inf) > > > > will be NAN (either sign) on the true side and > > [-Inf, Inf] !NAN on the false side. > > Sweet, that's exactly what I thought, thus the patch. > > Furthermore, for !HONOR_NANS I would expect the NAN sides above to be > UNDEFINED/unreachable. That is, the false side of x <= Inf when > !HONOR_NANS is unreachable. In practice, there is no real format that has NaNs and doesn't have Infs or vice versa and similarly we have just one switch to cover both Infinities and NaNs, so either both are supported, or neither of them, or both are supported but neither of them should appear in a valid program (-ffinite-math-only on most floating point formats). So the answer in that case is a little bit fuzzy because one shouldn't compare against infinity in that case (or for !MODE_HAS_INFINITIES even can't). But sure, if NaNs aren't possible or can't appear and you compare x <= Largest_possible_float, then it is always true and so UNDEFINED on the false edge. Jakub