Hello GCC, Greetings from Clang community! :-) I implemented _Float16 support in Clang.
On the Clang mailing list the request was made if we could rebrand __fp16 to a native half-precision type in Clang, but only for RISC-V. I objected to that for a few different reasons, and learned that the motivation was the unavailability of _Float16 in C++ mode in GCC. My request and proposal on the Clang list were to see about _Float16 support in C++ mode in GCC. In Clang, _Float16 is available in both C and C++ mode. Thus, while _Float16 is indeed a C ISO/IEC TS 18661-3 extension, we have also enabled it for C++ ahead of the outcome of the C++ standardisation story. The obvious benefit is that we have, for quite some time now, a good C/C++ story to target Arm hardware with native FP16 support from Clang, which we do not have for GCC. This divergence between GCC and Clang is something we would like to address, or at lease explore what the possibilities are. Very briefly about different half-precision source language types, in Arm we considering deprecating storage-only type __fp16, because with _Float16 and FP16 architecture extensions (RISC-V, ARM, etc.) there is no real good use-case for __fp16 anymore. Using it on modern hardware with FP16 support results in suboptimal results, and deprecating __fp16 addresses this and also the educational problem that we have of different behaving half-types. This is all a bit of a side story, but illustrates that for FP16 architecture extensions we want a native half-precision source language type. And our current best guess is that this is _Float16, also in C++ mode. There's undeniably a standardisation gap here for C++ (and also in C), but if we speculate about possible outcomes for C++, then I think it would have to behave largely the same as _Float16 (in C mode). And in case of changes, then I hope they are small, and implementations can easily adapt. While the latter would obviously not be entirely ideal, (early) implementations might also steer and benefit the standarisation story. So here's finally my concrete question: what do we think about making _Float16 available in C++ mode? Thanks, Sjoerd. ________________________________ From: Gcc <gcc-boun...@gcc.gnu.org> on behalf of Kito Cheng via Gcc <gcc@gcc.gnu.org> Sent: 11 March 2021 09:07 To: GCC <gcc@gcc.gnu.org> Cc: Joseph S. Myers <jos...@codesourcery.com> Subject: IEEE Interchange floating point and extended floating point for C++ Hi: Would it be possible to support interchange floating point and/or extended floating point for C++, which is introduced by ISO/IEC TS 18661-3? I've read the note about C++ support from the initial commit log[1], so I know there is some concern about C++ support for that, is it possible to enable that for C++ like a language extension for C++? The main demand comes from the data type for half-precision, ISO/IEC TS 18661-3 is the only common spec which supports half-precision and both GCC and clang are supported. However it can't be used on C++ for GCC, so it's hard to use that as a workable solution for half-precision data types. Or maybe ISO/IEC JTC1 SC22 WG14 N2016[2] is a better way for half-precision data types? Thanks [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c65699efcce48d68ef57ab3ce7fc5420fac5cbf9 [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2016.pdf
