On Thu, Jun 23, 2016 at 02:19:52PM +0000, Joseph Myers wrote: <snip>
> No GCC port supports a floating-point format suitable for _Float128x. > Although there is HFmode support for ARM and AArch64, use of that for > _Float16 is not enabled. Supporting _Float16 would require additional > work on the excess precision aspects of TS 18661-3: there are new > values of FLT_EVAL_METHOD, which are not currently supported in GCC, > and FLT_EVAL_METHOD == 0 now means that operations and constants on > types narrower than float are evaluated to the range and precision of > float. Implementing that, so that _Float16 gets evaluated with excess > range and precision, would involve changes to the excess precision > infrastructure so that the _Float16 case is enabled by default, unlike > the x87 case which is only enabled for -fexcess-precision=standard. > Other differences between _Float16 and __fp16 would also need to be > disentangled. Hi Joseph, Thanks for the patch. Just to let you know, I'm interested in trying to enable _Float16 for ARM/AArch64, and I'll be starting work on that once Jiong and Matthew's support for the ARMv8.2-A 16-bit floating point arithmetic extensions go in. These slightly complicate the description you give above as we now want two behaviours. Where the 16-bit floating point extensions are available, we want to use the native operations (FLT_EVAL_METHOD == 16). Where they are not available we want to use promotion to float (FLT_EVAL_METHOD == 0). I'm hoping that the excess precision mechanics will be able to handle this, and from your description above it sounds like making it work in the presence of the 16-bit arithmetic extensions will be easier as I won't have to modify the excess precision machinery much. As you say, I've also got a few things to do to disentangle _Float16 and __fp16. __fp16 should continue to always evaluate in excess precision, and we want it to continue to exist as a distinct type for compatability. My guess is that keeping this separation might not be too hard, I should only need to change TARGET_PROMOTED_TYPE to promote if it sees an __fp16 type, and do nothing otherwise. I'm hoping that enabling _Float16 for ARM/AArch64 should not be too difficult with the groundwork in your patches, but I would appreciate any pointers on where I am likely to run in to trouble; I haven't worked in the front-end before. Thanks, James