From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 058CE39960D4 for ; Fri, 12 Mar 2021 17:49:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 058CE39960D4 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: dQi2c4iBXUOqjk+CJ32LRMWYE6RLW8kOozrjdCAMotikPuTtfTaK1jHM/gPWLNzdC0l/wCJwuO aBUdA4Nm5yzqT4DO26KuBXJscqEZ74ybabwgHn4/IShfiNUm3ck/h7PmlGiRjOccNrv5/vU3tI b+Uhyg9OfRyKTRGfpl/8P+eJ2UG46vF9P98uT9H7hnt7VDTLYEPSUT1iQKJHpqM342IpetBgA6 QhGGjGBNNxMPPMZzYkB6UlhqMxWbj7TTvjEug7+5nvcUXn8vFpCpfUpdwv0DQuNsGxun3qCLGh gJ4= X-IronPort-AV: E=Sophos;i="5.81,244,1610438400"; d="scan'208";a="59031604" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 12 Mar 2021 09:49:35 -0800 IronPort-SDR: nViDI+efpHh7HtH2KxayWNuOF9UWpSFdhRs5M/qXeFc7GENw84hGtfIdHup6HOGsu45SF7D9ke MN5Z7J33STwePFB5W6FfvoQZJlSu+F3jqdPRwpNW08tppzqSPOrMJvG745tVlVuS3sHCFKBEuv UhzHUKyczOMmfyHhAPZSVDomXv1YtSSj0gcpmxdjsqf8UDTqdt18dzvIiAh3BlcLxAF57DyP8N dRoP/3Tdf7GoGmjbleG+zLs0jJCUT8vJgYm044CqkOuUpF2L3zxt+tJz13fCN09NVC9RAw7JHY qOw= Date: Fri, 12 Mar 2021 17:49:30 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Jonathan Wakely CC: Sjoerd Meijer , GCC , Kito Cheng Subject: Re: IEEE Interchange floating point and extended floating point for C++ In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3122.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 17:49:37 -0000 On Fri, 12 Mar 2021, Jonathan Wakely wrote: > On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc wrote: > > So here's finally my concrete question: what do we think about making _Float16 available in C++ mode? > > I think GCC should do it. What about types with the same format as an existing type (but which are nevertheless distinct types in C), such as _Float64 (typically same format as double) or _Float32 (typically same format as float, but not promoted when passed in variable arguments)? When those types escape into C++ code, they cause an ICE in name mangling; see bug 85518. (Incidental note on _Float16: various architectures have some hardware support for that format that don't have support for the type in GCC, although they may well have GCC built-in functions corresponding to the hardware support; also library support in glibc hasn't yet been implemented. In the case of x86_64 (F16C hardware conversion instructions from Ivy Bridge onwards), the psABI document defines an ABI for _Float16 and the corresponding complex type; in general such an ABI should be agreed with interested parties when adding _Float16 support for an architecture.) -- Joseph S. Myers joseph@codesourcery.com