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 01875385455F; Wed, 23 Nov 2022 13:10:54 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 01875385455F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669209055;
	bh=nsc9dvH+9Ph4jaus/ZyUbPVPf6SaREUwZvPJLaDwDok=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=u9zvNkatfJA7u0LfC1x6AIvN2Yow1922bflKZSAVh7MqVdwA5N2HWlxoWKZ6800Hi
	 46zD5yS10wnmWF8E+12nG/ylA6/mk5pQ4bTNQL/U47fmTJPhPo7qnSFQ9dxpXuFZrk
	 OOzstGIe6Lw3J0/HMwCpcX9IkiFdUG8XOH5aJ3U8=
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
Date: Wed, 23 Nov 2022 13:10:54 +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: <bug-107815-4-5JQT2Jukgc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107815-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107815-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot U=
ni-Bielefeld.DE> ---
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>> 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.

One thing that is also weird is that gdb prints u as infinity here, but
that may well a gdb quirk.

(gdb) p/x u
$2 =3D 0x7ffeffffffffffffffffffffffffffff
(gdb) ptype u
type =3D _Float128

> This is weird.  If line 66 is reached, fmt must be std::chars_format::fix=
ed
> and in that case ptr1 - str1 should be 4933 and str1 should be that many =
chars
> long string starting with
> 1189731495357231765085759326628007016196469052641694045529698884212163579=
755312392324974012848462073525902033564749126859755265433573804462672698751=
9452614908534619587250212628458657994054044935746815
> If you get just 1e+4932 when asked for fixed format, something is just wr=
ong,
> that is scientific or general format.

I found that sprintf_ld returns 7 for the value above.  It is called
with

Thread 2 hit Breakpoint 1, 0xff0efd9c in std::(anonymous
namespace)::sprintf_ld<long double> (value=3Dinfinity, format_string=3D0xfe=
fcec38
"%.0Lf", length=3D4934, buffer=3D0xffbfe8c8 "\177\376", '\377' <repeats 14 =
times>)
at
/vol/gcc/src/hg/master/local/libstdc++-v3/src/c++17/floating_to_chars.cc:10=
52

and a simple

        sprintf (buf, "%.0Lf", (long double) LDBL_MAX);

indeed returns 7.=