public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE Date: Wed, 24 Feb 2021 17:26:59 +0000 [thread overview] Message-ID: <bug-98384-4-991blxsBxw@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-98384-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:70aa0e6eef9d65744f37adc2a3cffef1a8217dc1 commit r11-7367-g70aa0e6eef9d65744f37adc2a3cffef1a8217dc1 Author: Patrick Palka <ppalka@redhat.com> Date: Wed Feb 24 12:24:43 2021 -0500 libstdc++: Robustify long double std::to_chars testcase [PR98384] The long double std::to_chars testcase currently verifies the correctness of its output by comparing it to that of printf, so if there's a mismatch between to_chars and printf, the test FAILs. This works well for the scientific, fixed and general formatting modes, because the corresponding printf conversion specifiers (%e, %f and %g) are rigidly specified. But this doesn't work well for the hex formatting mode because the corresponding printf conversion specifier %a is more flexibly specified. For instance, the hexadecimal forms 0x1p+0, 0x2p-1, 0x4p-2 and 0x8p-3 are all equivalent and valid outputs of the %a specifier for the number 1. The apparent freedom here is the choice of leading hex digit -- the standard just requires that the leading hex digit is nonzero for normalized numbers. Currently, our hexadecimal formatting implementation uses 0/1/2 as the leading hex digit for floating point types that have an implicit leading mantissa bit which in practice means all supported floating point types except x86 long double. The latter type has a 64 bit mantissa with an explicit leading mantissa bit, and for this type our implementation uses the most significant four bits of the mantissa as leading hex digit. This seems to be consistent with most printf implementations, but not all, as PR98384 illustrates. In order to avoid false-positive FAILs due to arbitrary disagreement between to_chars and printf about the choice of leading hex digit, this patch makes the testcase's verification via printf conditional on the leading hex digits first agreeing. An additional verification step is also added: round-tripping the output of to_chars through from_chars should recover the value exactly. libstdc++-v3/ChangeLog: PR libstdc++/98384 * testsuite/20_util/to_chars/long_double.cc: Include <optional>. (test01): Simplify verifying the nearby values by using a 2-iteration loop and a dedicated output buffer to check that the nearby values are different. Factor out the printf-based verification into a local function, and check that the leading hex digits agree before comparing to the output of printf. Also verify the output by round-tripping it through from_chars.
next prev parent reply other threads:[~2021-02-24 17:26 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-18 21:39 [Bug libstdc++/98384] New: " seurer at gcc dot gnu.org 2020-12-21 20:28 ` [Bug libstdc++/98384] " ppalka at gcc dot gnu.org 2020-12-22 9:23 ` ro at gcc dot gnu.org 2021-01-05 9:10 ` [Bug libstdc++/98384] [11 Regression] " rguenth at gcc dot gnu.org 2021-01-07 13:04 ` iains at gcc dot gnu.org 2021-01-07 15:42 ` ppalka at gcc dot gnu.org 2021-01-07 16:41 ` iains at gcc dot gnu.org 2021-01-07 17:42 ` cvs-commit at gcc dot gnu.org 2021-01-07 17:55 ` ppalka at gcc dot gnu.org 2021-01-08 9:30 ` ro at CeBiTec dot Uni-Bielefeld.DE 2021-01-12 16:35 ` ppalka at gcc dot gnu.org 2021-01-14 11:13 ` rguenth at gcc dot gnu.org 2021-02-12 15:02 ` jakub at gcc dot gnu.org 2021-02-23 2:49 ` cvs-commit at gcc dot gnu.org 2021-02-23 16:55 ` ppalka at gcc dot gnu.org 2021-02-24 9:58 ` ro at CeBiTec dot Uni-Bielefeld.DE 2021-02-24 15:14 ` ppalka at gcc dot gnu.org 2021-02-24 15:42 ` ro at CeBiTec dot Uni-Bielefeld.DE 2021-02-24 15:48 ` jakub at gcc dot gnu.org 2021-02-24 16:16 ` ppalka at gcc dot gnu.org 2021-02-24 16:26 ` iains at gcc dot gnu.org 2021-02-24 16:45 ` ppalka at gcc dot gnu.org 2021-02-24 17:26 ` cvs-commit at gcc dot gnu.org [this message] 2021-02-27 16:17 ` iains at gcc dot gnu.org 2021-02-27 16:49 ` dje at gcc dot gnu.org 2021-03-03 14:28 ` ppalka at gcc dot gnu.org 2021-03-05 2:37 ` dje at gcc dot gnu.org 2021-03-08 17:42 ` ppalka at gcc dot gnu.org 2021-03-08 17:53 ` schwab@linux-m68k.org 2021-03-08 19:27 ` dje at gcc dot gnu.org 2021-03-08 21:09 ` iains at gcc dot gnu.org 2021-03-08 21:24 ` iains at gcc dot gnu.org 2021-03-09 9:55 ` iains at gcc dot gnu.org 2021-03-10 14:28 ` ppalka at gcc dot gnu.org 2021-03-10 14:51 ` ppalka at gcc dot gnu.org 2021-04-08 15:11 ` cvs-commit at gcc dot gnu.org 2021-04-08 15:22 ` [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails ppalka at gcc dot gnu.org 2021-04-08 16:22 ` redi at gcc dot gnu.org 2021-04-27 11:39 ` jakub at gcc dot gnu.org 2021-07-28 7:05 ` rguenth at gcc dot gnu.org 2022-04-21 7:48 ` rguenth at gcc dot gnu.org 2023-05-29 10:03 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-98384-4-991blxsBxw@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).