From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0DB643857342; Wed, 7 Jun 2023 17:28:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DB643857342 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1686158892; bh=gT6uTiyNfH8Y+qKBZmQfIt3vt1P2GmnpHc2n7VH5zCQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=b3JaY1YDXAKhnAtlPBFPLvJsDu46tW0FD/TTeuqucOZ+/PGFfP1sB3306BRCAZT9w 4jGUn6JmADJXZ079sLYN5wWsntEp2PoWlOTlhBd4CAGkAq3eXZLVCp1YMKi70OmbCa VkJFbd3o+/paKO5Z4smp9PnDn9GNWU22sdvTXmNE= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard Date: Wed, 07 Jun 2023 17:28:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110145 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:88e7f1f7ee67462713a89104ae07e99b191d5e2c commit r14-1619-g88e7f1f7ee67462713a89104ae07e99b191d5e2c Author: Jakub Jelinek Date: Wed Jun 7 19:27:35 2023 +0200 libstdc++: Fix up 20_util/to_chars/double.cc test for excess precision [PR110145] This test apparently contains 3 problematic floating point constants, 1e126, 4.91e-6 and 5.547e-6. These constants suffer from double roundi= ng when -fexcess-precision=3Dstandard evaluates double constants in the precision of Intel extended 80-bit long double. As written in the PR, e.g. the first one is 0x1.7a2ecc414a03f7ff6ca1cb527787b130a97d51e51202365p+418 in the precision of GCC's internal format, 80-bit long double has 63-bit precision, so the above constant rounded to long double is 0x1.7a2ecc414a03f800p+418L (the least significant bit in the 0 before p isn't there already). 0x1.7a2ecc414a03f800p+418L rounded to IEEE double is 0x1.7a2ecc414a040p+418. Now, if excess precision doesn't happen and we round the GCC's internal format number directly to double, it is 0x1.7a2ecc414a03fp+418 and that is the number the test expects. One can see it on x86-64 (where excess precision to long double doesn't happen) where double(1e126L) !=3D 1e126. The other two constants suffer from the same problem. The following patch tweaks the testcase, such that those problematic constants are used only if FLT_EVAL_METHOD is 0 or 1 (i.e. when we have guarantee the constants will be evaluated in double precision), plus adds corresponding tests with hexadecimal constants which don't suffer from this excess precision problem, they are exact in double and long double can hold all double values. 2023-06-07 Jakub Jelinek PR libstdc++/110145 * testsuite/20_util/to_chars/double.cc: Include . (double_to_chars_test_cases, double_scientific_precision_to_chars_test_cases_2, double_fixed_precision_to_chars_test_cases_2): #if out 1e126, 4.91e-6 and 5.547e-6 tests if FLT_EVAL_METHOD is negative or larger tha= n 1. Add unconditional tests with corresponding double constants 0x1.7a2ecc414a03fp+418, 0x1.4981285e98e79p-18 and 0x1.7440bbff418b9p-18.=