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 533313858413; Mon,  5 Feb 2024 14:29:30 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 533313858413
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707143370;
	bh=/CIYm6qMaekD9d7M6jbnsIcTL5SLV7gsZug6e8qjEe4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=vHdadj/Qx9+LOFPSKnfBYqMh6rQGz8PJZNVgSJqKcisRECnR5AaUk1BZsCYJOU18a
	 D74ehSzeaa8kwLSbYEu39vEWPHCDD0KPezX4N5O1352c3y2Yyk2IaqoyaVQ813RQQZ
	 5qb9ioPOmkSaKBKabBJfYqVuWIFoJF9G1A8yMp5Y=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/113770] _Float64x support on g++ 13.2.0
Date: Mon, 05 Feb 2024 14:29:29 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113770-4-I1VRRX0KwD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113770-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113770-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=3D113770

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Masahide Kashiwagi from comment #0)
> I have noticed that the following simple program will not complie
> with g++ 13.2.0 on ubuntu 23.04 .
>=20
> #include <iostream>
>=20
> int main()
> {
>         _Float64x a;
>=20
>         std::cin >> a;

This is expected, _Float64x is not defined in any C++ standard, and there i=
s no
support for it in the standard library.

> }
>=20
> It compiles fine with long double and __float80.

Of course, because long double is a standard type, and __float80 is a typed=
ef
for long double on x86_64.

> Also no problem with clang++ 16.0.6.
>=20
> I also noticed that with _Float64x, the numeric_limits<_Float64x> return =
0,

That's also expected. It's not a standard type, and the standard library
doesn't know anything about it.

> as shown below.
>=20
> #include <iostream>
> #include <limits>
>=20
> int main()
> {
>         std::cout << std::numeric_limits<_Float64x>::epsilon() << std::en=
dl;
>         std::cout << std::numeric_limits<_Float64x>::max() << std::endl;
>         std::cout << std::numeric_limits<_Float64x>::min() << std::endl;
>         std::cout << std::numeric_limits<_Float64x>::infinity() << std::e=
ndl;
> }
>=20
> This program returns 0:
>=20
> 0
> 0
> 0
> 0
>=20
> With long double and __float80, the program returns correct values:
>=20
> 1.0842e-19
> 1.18973e+4932
> 3.3621e-4932
> inf

For the same reason given above.

> It seems to me that g++ 13 cannot handle _Float64 correctly.

I assume that's a typo, as it handles _Float64 properly, because that's
std::float64_t which is a standard type.

> Is there any way to deal with this?

Don't use _Float64x in C++?=