From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id B2ED33896C18 for ; Wed, 25 Nov 2020 19:27:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B2ED33896C18 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: Y4eN+avbk1gTSiX77PrH/2+5F+NYJKHyKUgbWBlJdUIi20PgFHK+XFQSEnHsmp05+el0OdW//N RQ2+7d7oczeFllbZvUuaFSM0b+z7tb3iqtEPKd9wyDjhlVGiPIm2EJq5qkTiloN1Ws6iyxWNyb LLTN6eC7v9ur7tBqrpslwwmgIunGi8lHu3S0Tsl/Xk8V3bl+eX9yB4O638X25LyMm6Adhea4Fd JujuV0mouAMYPlgbNK3Xgb5fP1JAbbyrc5Oh4b8u1iWAyWkLg2tP1LCpW5aQ8w7VN9LLzr+nRo fdw= X-IronPort-AV: E=Sophos;i="5.78,370,1599552000"; d="scan'208";a="55477893" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 25 Nov 2020 11:27:51 -0800 IronPort-SDR: K6+Ekkba5LpU23mQ64+B+g1rEVVFgM4be533SsIJcUK1D9SITtDftU5FMw1pG3P7BaMF3Gp6Dl nXH4l1VBgvdg64fJA+4Ir8vMx1CZ6YVe5ioe6uy4DxDglFpaf9oofTDC6vOYCfE4kLEXqSlKWw 1ett5Dl7d2oSzG+pcI/NZAkstgGXoGCHbGvCwg55Pdpre0mnocScaf6RraAQakxLbtwgG587Lp gp8CclpKqXxa9plZ7ix2v5xCPCrJGkkfturtC++Ap8B27yJOxTN6ZgO9j6WGiAXb9CV1RQZSyC 2hY= Date: Wed, 25 Nov 2020 19:27:46 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Siddhesh Poyarekar CC: Florian Weimer , , Siddhesh Poyarekar via Libc-alpha , Carlos O'Donell Subject: Re: unnormal Intel 80-bit long doubles and isnanl In-Reply-To: Message-ID: References: <6663b7b7-7e5b-8987-bd0d-82bceb772951@gotplt.org> 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-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-1042.8 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:27:54 -0000 On Wed, 25 Nov 2020, Siddhesh Poyarekar wrote: > Would you agree to treating unnormals as NaNs and consequently have glibc > provide that guarantee in the library instead of either declaring it undefined > or maintaining the status quo, i.e. keeping it unspecified? I think it would be a pain to maintain test coverage for unnormals (and presumably all the other kinds of unsupported operands, and you'd need to work out what semantics you want for pseudo-denormals as well since those are the one kind of such representation the processor doesn't raise "invalid" for) for all the functions with floating-point arguments - and claiming to handle those consistently requires having such test coverage (there are only a few tests for such format-specific representations in sysdeps/ieee754/ldbl-96 at present). But maybe you could set up some mechanism by which, when gen-libm-test.py processes a test using snan_value or snan_value_ld (but not snan_value_pl), and the relevant format is one of the format variants that has these representations, it automatically generates tests for all those variants (that the processor raises "invalid" for when handling as operands, i.e. treats much like sNaN). I'm not sure if it's actually possible to generate a static initializer for a long double value with one of those representations, or only for a union containing a long double where another member is initialized; if a union type needs to be used in the tables of test inputs, that further complicates things. -- Joseph S. Myers joseph@codesourcery.com