From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5869E3858C2B; Tue, 22 Nov 2022 16:10:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5869E3858C2B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669133406; bh=kThgcvxAm9OAzKuYVDrHPGh+bJzvgZ7lbm5XvdqwH1Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rpyHL8MF2mx/2KmpekaQm6YyoCPo3hBmqd6ElIl1LrmSz8tjTMheHOSLtRZ3wpWXJ VYuY6GT318mRwKKAuLdJUl8r9mG2Dy3fu9gSy/P/TR2d0RRyGllaFFV8tqjU7Ebq3s tI3nXqDJeIcfjfiiODffo7ET0DHcUY1Ekg/D1N8M= From: "ro at CeBiTec dot Uni-Bielefeld.DE" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs Date: Tue, 22 Nov 2022 16:10:05 +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: ro at CeBiTec dot Uni-Bielefeld.DE 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 #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- 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? Sure. This is supposed to print u, I assume ;-) The line before the assertion failure is 1.18973e+4932 1e+4932 /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/float1= 28_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 =3D=3D std::errc() && ptr2 - s= tr2 =3D=3D ptr1 - str1' failed. i.e. LDBL_MAX. > If line 66 fails, it is a fixed printing test trying to verify > that the string created by line 60 was actually the minimal. It doesn't now reliably: I compiled with -g3 -O0 to be able to check things with gdb if needed. > On SPARC Solaris, I assume long double is IEEE quad, and it is the shorte= st > version, so should use ryu library for both cases. It is, although only ever implemented in software. > 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 sho= uld > use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS doesn't > support newlocale/uselocale/freelocale most likely just strtod with lost > precision (so in that case the test would fail) on line 74. 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.=