From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 9E0CE3896C11; Wed, 10 Mar 2021 14:51:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E0CE3896C11
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
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppalka at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: ppalka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-98384-4-L6iGb6LolO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-98384-4@http.gcc.gnu.org/bugzilla/>
References: <bug-98384-4@http.gcc.gnu.org/bugzilla/>
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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Mar 2021 14:51:48 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98384

--- 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
> >=20
> > * the test at line 83 fails, and with some more debugging stuff inserte=
d and
> > the abort removed, there are 66 cases where the strings do not agree, s=
o a
> > bug in libc (probably) .. I'm doing seem more tests on a newer system
> > version.
>=20
> 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:
>=20
> 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
>=20
> (and similarly for the other values that fail, not read the code enough y=
et
> 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.=