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 CAB083857815; Thu, 31 Dec 2020 23:09:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CAB083857815 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: 3EnS5iLkDE5eTiDSPjeRb1KQ0TKB1tXrUpFioW7+Zn2KXcXkN7sTEFi4y8KHtXrozHylpQO2wA hXyan1wcRKMhDYt1tbYd/VUntHyrolDZnUCCqSc9hgX99cZ0brWSwYwlK4+XFQXPenwotwFaKg vOMR2H7nuwEYZO4xpvzuIudPzkd1fbztPIWttOT8MRLCpWmb/YmMPXGsaW0O3FrBXJOHYaFJva jt7GN2mcsZhjPJPqQuFNS9I1aymEHLIKN2I2yP3M31cb1itwUG4FAC1y1AitqFEsrplhRolSnQ I2E= X-IronPort-AV: E=Sophos;i="5.78,464,1599552000"; d="scan'208";a="56821176" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 31 Dec 2020 15:09:20 -0800 IronPort-SDR: 0JJuFq44iGM6+OdZqZJP0iXvRtbw4JzPDA73197cAyTDX0fe3ArU+yPbGPKe7gGzxs3SbtMk7u lg5tKbEr5PryMEbTtWOElxFfSQ0fWzG4H2zmLEXkBZ6dFQW4VcYJKI72sz8DAe4G0ERnj9sLEt HuosmD1skdO6if3zkIF9hed9Ykxtm+fXY72eL7t/XmDRyIF+Lr+ONtTa7Q9F1bTfEYCALN8Rc6 Zl1v/vcj46nvqXGCfb7l2PjPlz2HxghBPdJs+Zhws/YWbtsBcYGDgUNKPSdHqEzH7I1gRdPVXd k1E= Date: Thu, 31 Dec 2020 23:09:15 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Siddhesh Poyarekar CC: , Subject: Re: [PATCH v3 2/2] x86 long double: Add tests for pseudo normal numbers In-Reply-To: <20201224024554.3579622-3-siddhesh@sourceware.org> Message-ID: References: <20201224024554.3579622-1-siddhesh@sourceware.org> <20201224024554.3579622-3-siddhesh@sourceware.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-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3124.1 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: Thu, 31 Dec 2020 23:09:23 -0000 On Thu, 24 Dec 2020, Siddhesh Poyarekar via Libc-alpha wrote: > Add some tests for fpclassify, isnan, isinf and issignaling. This looks like these tests get duplicated for every floating-point type for which they are run. They should only be run for long double and _Float64x; when the libm tests are run for other floating-point types (choices of FLOAT), these new tests should be compiled out. Note that "f" in the test macro names means FLOAT, but these tests seem always to test long double, indpendent of the choice of FLOAT, not FLOAT. (The second argument of nexttoward is the only case where it's *correct* for a math/ test to use long double independent of FLOAT.) Properly testing _Float64x (i.e. with that as the argument type to the macro, not long double, when FLOAT is _Float64x) may need further changes; either not using the math_ldbl.h unions but a local union with FLOAT, or casting the argument to type FLOAT. > +/* For pseudo-normal number tests. */ > +#if HANDLE_PSEUDO_NUMBERS > +# include > +#define pseudo_inf { .parts = { 0x00000000, 0x00000000, 0x7fff }} > +#define pseudo_zero { .parts = { 0x00000000, 0x00000000, 0x0100 }} > +#define pseudo_qnan { .parts = { 0x00000001, 0x00000000, 0x7fff }} > +#define pseudo_snan { .parts = { 0x00000001, 0x40000000, 0x7fff }} > +#define pseudo_unnormal { .parts = { 0x00000001, 0x40000000, 0x0100 }} I think the right condition here (and everywhere in this patch) is TEST_COND_intel96: a condition on the format for which the tests are being run rather than on how glibc is built. The tests are both specific to rules for that format about which encodings are valid (the high bit of the significand is unspecified for NaNs and infinities for m68k), and, in the form in which they're written here, also specific to little-endian, since you're relying on the ordering of initializer elements rather than using designated initializers, so wouldn't work on m68k for that reason as well. If you need to avoid these tests for ia64 because of different rules on such encodings for ia64, some other condition might then be used *inside* a TEST_COND_intel96 condition. -- Joseph S. Myers joseph@codesourcery.com