[cfe-dev] [RFC] Having different behavior for __fp16 on RISC-V

James Y Knight via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 11 10:43:08 PST 2021

On Thu, Mar 11, 2021 at 11:20 AM Sjoerd Meijer via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> In fact there is kind of awkward story behind this, we chose __fp16 rather
> than _Float16, major reason is GCC supporting, and also we saw ARM/AArch64
> deprecated that for a while, but _Float16 problem still there in GCC, so we
> decide to using __fp16 rather than _Float16.
> I am not really following this.
> And we also considering the compatible issue there, I mean the
> compatibility of ACLE's __fp16, __fp16 isn't a language extension for GCC,
> it's a target specific type for ARM/AArch64, so if we don't define that as
> a formal extension types, then we have broken support/compiler
> compatibility issue on this due to GCC didn't support __fp16 as language
> extension.
> And am not entirely sure about this.
> I don't think I have changed my mind on this topic, and I don't know what
> else/more I can add to what I have already mentioned.
> I won't repeat my arguments, but the bottom line is that we want to
> deprecate __fp16, while you like to rebrand it to a native half-precision
> type, and I don't see how this goes together very well. I also remain
> unconvinced about the arguments against _Float16, which I think is the
> solution.
> I don't know what your options are now. Maybe someone else can weigh in
> and shine a light on this, perhaps I am missing something. I don't know if
> you can go ahead and make these changes if you get an LGTM from someone
> else, but I hope the community sees the problem of the same type behaving
> different on different targets.

I don't know why _Float16 isn't implemented by GCC in C++ mode, but I'd
agree that using _Float16 for RISC-V, and adding support for _Float16 to
GCC's C++ mode does seem like the better solution here, especially given
that such support will also be needed for ARM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210311/fdd6ca92/attachment.html>

More information about the cfe-dev mailing list