From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A60D0385142A; Wed, 24 Aug 2022 17:35:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A60D0385142A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1661362505; bh=aIumEPVv/5v42L8zGSHN4AM+PQVLSwDxszQkvjOHtqY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nH4q0bPCNfMTHAZpAG+NOS4h9FdlfBsK9MdWDsCbwZBZQN94r5yKi4sPvlOfRB+HG LWXCAUWG+BZ4eD2HWOVo5f7RMTL/98KB1SmM5EV6DCW8lP3kmeU8qQkkm7E0WxAaEu Amz30eY8JYd9tIU5WHm1QTwpqgfJSRCLozjMhfQw= From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names Date: Wed, 24 Aug 2022 17:35:05 +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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com 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: 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=3D106652 --- Comment #4 from joseph at codesourcery dot com --- Regarding mangling: I expect this change should fix bug 85518. General: I expect some glibc header changes might be appropriate, where=20 they currently assume __FloatN keywords aren't supported in C++. And=20 where glibc headers handle type-generic operations for C++ by defining=20 appropriate overloaded functions in the headers, make sure the overloads=20 for _Float128 work with both _Float128 and __float128 where supported and=20 distinct, or otherwise adjust the headers as needed to handle both types. (Also, so far we don't have _Float16 support in glibc, and while it would=20 be a sensible feature in principle, there would be issues to consider with= =20 the impact on minimum GCC versions for building glibc on relevant=20 architectures, unless some kind of hack is used to allow _Float16=20 functions to be built and to get the correct ABI even when built with an=20 older compiler. Requiring GCC 7 to build glibc for AArch64 and Arm might=20 well be reasonable now; requiring GCC 12 for x86/x86_64 or GCC 13 for=20 RISC-V probably not for a few years.)=