public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ppalka 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, 10 Mar 2021 14:51:48 +0000	[thread overview]
Message-ID: <bug-98384-4-L6iGb6LolO@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 #31 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #28)
> (In reply to Iain Sandoe from comment #27)
> > for Darwin x86
> > 
> > * the test at line 83 fails, and with some more debugging stuff inserted and
> > the abort removed, there are 66 cases where the strings do not agree, so a
> > bug in libc (probably) .. I'm doing seem more tests on a newer system
> > version.
> 
> repeated on macOS11 (Darwin20) - the fails are for precisions 1, 5, 9 and 13
> (if there's any significance to that) with a pattern that looks like this:
> 
> begin 9.2p-11003, printf_buffer 0x9.1p-11003
> FAILED: prec has value 1
> --
> begin 9.1a2b4p-11003, printf_buffer 0x9.1a2b3p-11003
> FAILED: prec has value 5
> --
> begin 9.1a2b3c4d6p-11003, printf_buffer 0x9.1a2b3c4d5p-11003
> FAILED: prec has value 9
> --
> begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
> FAILED: prec has value 13
> --
> begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
> FAILED: prec has value 13
> --
> begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
> FAILED: prec has value 13
> 
> (and similarly for the other values that fail, not read the code enough yet
> to figure out why we get the three cases for 13...).

Thanks for digging into this!  So it looks like the disagreement here is the
rounding of the least significant hexit.  Assuming the FP rounding mode is set
to FE_TONEAREST, seems like a bug in printf indeed.. I can't think of any
reason why this happens only with precisions 1,5,9 and 13 and not also with
3,7,11.

  parent reply	other threads:[~2021-03-10 14:51 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
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 [this message]
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-L6iGb6LolO@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: link
Be 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).