From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7D88D38582BF; Fri, 9 Sep 2022 09:44:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D88D38582BF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662716685; bh=d9vgJsKK3ZYQvKiAzIm+CcU6UqlSggVQxgZTcGJGjzc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gooFMT/ewF/N2ocTd6md2S3/g7n9vz8RftIMHbXlIaYjyAzdvLnYxwAUwXXCxKqiP SgxXuB2YXUqrVBB/osnTCHyZtV9FUXJnGseedwDZ2CyfHOT0Xwl5tw3kWi+9523s3p FdxIsjufvZJdZH3GO/npJIy4QiuJKegt0UvvuCjs= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names Date: Fri, 09 Sep 2022 09:44:43 +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: 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created 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 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #53508|0 |1 is obsolete| | --- Comment #8 from Jakub Jelinek --- Created attachment 53555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D53555&action=3Dedit gcc13-pr106652-wip.patch Some further progress. Introduces a helper extended_float_type_p and uses = it and attempts to implement 2) from above and add some testcase coverage for = it (not complete, because right now there are just float{16,32,64,128} effecti= ve targets and not effective targets for various float/double/long double type properties (e.g. if they are ieee type), so for the cases where there shoul= d be an error on the conversion I've kept only cases where I know for sure using= the above mentioned effective targets, not where it is sometimes the case and sometimes it isn't. From the above list, 1) needs decision what to do about arithmetics in that type, 4) needs discussion on where to diagnose it, 5) n= eeds implementation.=