From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6DE5E386103A; Wed, 24 Feb 2021 16:16:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6DE5E386103A From: "ppalka at gcc dot 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 16:16:40 +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: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 16:16:40 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98384 --- Comment #16 from Patrick Palka --- (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14) > > --- Comment #13 from Patrick Palka --- > [...] > > So: > > > > 1. The hex-form conversion specifier doesn't trim trailing zeroes. >=20 > Which according to ISO C 2017, p.228, is allowed: "trailing zeros may > be omitted". Ack. >=20 > > 2. The fixed-form conversion specifier sometimes outputs the > > scientific-notation suffix "e+00". >=20 > This is unexpected indeed. >=20 > > 3. The fixed-form conversion specifier sometimes outputs the scientific= form. >=20 > Same. However, g++ -Wall complains: >=20 > pr98384.cc: In function =E2=80=98int main()=E2=80=99: > pr98384.cc:5:13: warning: unknown conversion type character =E2=80=98.=E2= =80=99 in format > [-Wformat=3D] > 5 | printf("%L.1000f\n", 1.0L); > | ^ > pr98384.cc:5:10: warning: too many arguments for format [-Wformat-extra-a= rgs] > 5 | printf("%L.1000f\n", 1.0L); > | ^~~~~~~~~~~~ Whoops, that line should say printf("%.1000Lf\n", 1.0L) as Jakub pointed ou= t.=20 With that change the testcase in #c13 should be valid, and the unexpected "e+00" suffix is still present in the output. >=20 > Compiling the equivalent C version with Studio 12.6 cc gives: >=20 > "pr98384.c", line 6: warning: conversion of hex floating-point constant > cannot be represented exactly in its evaluation format >=20 > > Each of the to_chars/printf mismatches I've looked at seem to be caused= by one > > of these three issues. Should we just XFAIL the test on Solaris? >=20 > Only if it's clear that those outputs are in violation of the standard > and the inputs are valid: the warnings above cast some doubt upon the > latter. It seems the second and third issue alone make the printf implementation nonconforming (but not the first issue as you pointed out). Ideally the libstdc++ testcase ought to not assume the 'a' printf specifier trims trail= ing zeros, but even with that fixed it seems we still might have to XFAIL on Solaris due to the second and third issue? (In reply to Jakub Jelinek from comment #15) > printf("%L.1000f\n", 1.0L); >=20 > The length modifier needs to come after precision, not before it, so > you should be using > printf("%.1000Lf\n", 1.0L); > instead. > But the test nor libstdc++ itself doesn't do that, does it? Fortunately not, I just messed up transforming 'print("%.*Lf", 1000, ...)' = into 'printf("%.1000Lf", ...)' inline in the #c13 testcase :)=