From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 171373858C2F; Tue, 22 Nov 2022 17:22:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 171373858C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669137740; bh=YHL3oP9GUm8Hp/HE1tdsJJy21/cPj+bBSWuffB73MUM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=P56h5rdunIDtu4S6Lnjn4R9vFltFkIwY3e+oQQ/6ejFu5xyTQVK7ScXOGwz45kRKV 0YF0MAAbWVwF1k31z6bWGts+RTd6NCzDR2VxN2YkJeErS/Zm/1oalGCj0XX8uVDnEB 20RoCnGn+l62ZxBkFFukxE8oJvetCoHX2rpYnuL4= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs Date: Tue, 22 Nov 2022 17:22:19 +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: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107815 --- Comment #3 from Jakub Jelinek --- (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2) > > --- Comment #1 from Jakub Jelinek --- > > Can you please uncomment the > > // std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n'; > > and > > // std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n'; > > lines in the test, so that it is clear at least which test it is on? >=20 > Sure. This is supposed to print u, I assume ;-) Oops, sure. >=20 > The line before the assertion failure is >=20 > 1.18973e+4932 1e+4932 > /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/ > float128_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 =3D=3D > std::errc() && ptr2 - str2 =3D=3D ptr1 - str1' failed. >=20 > i.e. LDBL_MAX. This is weird. If line 66 is reached, fmt must be std::chars_format::fixed and in that case ptr1 - str1 should be 4933 and str1 should be that many ch= ars long string starting with 118973149535723176508575932662800701619646905264169404552969888421216357975= 531239232497401284846207352590203356474912685975526543357380446267269875194= 52614908534619587250212628458657994054044935746815 If you get just 1e+4932 when asked for fixed format, something is just wron= g, that is scientific or general format. >=20 > > If line 66 fails, it is a fixed printing test trying to verify > > that the string created by line 60 was actually the minimal. >=20 > It doesn't now reliably: I compiled with -g3 -O0 to be able to check > things with gdb if needed. >=20 > > On SPARC Solaris, I assume long double is IEEE quad, and it is the shor= test > > version, so should use ryu library for both cases. >=20 > It is, although only ever implemented in software. >=20 > > Line 74 failure is about whether the created string can be read back, > > in that case for IEEE quad fast_float library can't be used and so it s= hould > > use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS does= n't > > support newlocale/uselocale/freelocale most likely just strtod with lost > > precision (so in that case the test would fail) on line 74. >=20 > I'm not seeing the failure on l.74 any longer, even with the default > optimization options. There has been an effort to introduce an xpg7 > locale, but that had quite a number of unresolved issues (both on AIX > and Solaris) and was never finished. Currently, we're stuck with > generic.=