From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 634DF3858409 for ; Fri, 31 Dec 2021 17:05:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 634DF3858409 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: GaMq3fX3Xz//hhETzD8LRlZrZEevUz5GsYubjnMhUrD8jKVkl/cUu7b8uxIEBeCm7hAeFoqv7M 1V4VXEYdneNZTwY7mM4KR4XekESWnQx0w2lrGB8FYJkrfJvBx1B0iJzHjRzNq9Uk/yfsNNkJTf 5CYfkHlfPyhn7ise8pzUtOe7TabJFH5ByEepTvSVs9+870GjbCLdOjYAu7F/JZSbvU2RXf1FWF wFFy4xsXqO2r4wRUpB8t/o6Q/G+TkDbQvu4ksAKDpZs9rC4JrJNl0MaxbeEnt3t07XVs+ZCBNx bKkqQ037FDb5FxdCvpwDhwDh X-IronPort-AV: E=Sophos;i="5.88,252,1635235200"; d="scan'208";a="70269134" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 31 Dec 2021 09:05:36 -0800 IronPort-SDR: Hs7JKqTmFgMAjP6ALMW1zsNjMs37VULanXDmX3FxhkbU5VDLTVGGCJ/ltijCjKVxchWSExpLme y9E7KO/xLRJnf68iFdC8FwchXDBBEiN+WcDTslF1bWaKWV+AYKLqbxOWYrbgrAe4yri0Agq7Z1 CZIOtqemJqvkzVxv3IuvaOcXWqVqa/W9vyoxfKPzDyKBJzZbC6kghqa9OCf9L/ADF41ghWAnwl +0h/VNOPS5rNki/KACCRqEBydA3iBwZhEY9TrNjO35etiKH0enmzXx2GmXEhBaRWuTumTf7pTS RYA= Date: Fri, 31 Dec 2021 17:05:30 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: FX CC: GCC Mailing List Subject: Re: Weird behaviour (bug?) of __builtin_nans() In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3115.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2021 17:05:38 -0000 On Fri, 31 Dec 2021, FX via Gcc wrote: > The reason I ended up in this rabbit hole is that I am implementing some > handling of signalling NaNs in libgfortran. Could someone either confirm > that the behavior observed above is a bug, or if not, kindly explain to > me why it happens? 1. You should use -fsignaling-nans if you want signaling NaNs to work correctly. 2. I suspect this has the same, or similar, underlying cause to bug 86367 (whatever that cause is): something is interpreting conversions between types with the same floating-point format (in this case, the same type but using a typedef name on one side of the conversion) as being a convertFormat operation - but apparently only without -fsignaling-nans. 3. There is probably a reasonable case for interpreting such conversions (including casts) as copy operations instead, including in the absence of -fsignaling-nans; C23 Annex F leaves that implementation-defined, and handling such conversions as copy operations is likely to be more predictable and more useful. 4. Note however that in some cases the ABI may mean the conversion has to be treated as convertFormat (returning float or double on 32-bit x86, in particular, because that return uses an x87 register). 5. In other cases on 32-bit x86, the failure of GCC to model excess precision explicitly by default (instead pretending the machine has SFmode and DFmode loads and stores) makes it hard to avoid spurious conversions (even in some cases where there is no floating-point operation or lvalue-to-rvalue conversion at all in the abstract machine and so -fsignaling-nans shouldn't be needed at all, see bugs 58416, 71460, 93934). -- Joseph S. Myers joseph@codesourcery.com