Re: Implement C _FloatN, _FloatNx types [version 6]

[Joseph Myers <joseph@codesourcery.com>]

On Fri, 19 Aug 2016, Szabolcs Nagy wrote:

> On 17/08/16 21:17, Joseph Myers wrote:
> > 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.
> 
> i wonder how gcc can support _Float16 without excess
> precision.
> 
> using FLT_EVAL_METHOD==16 can break conforming c99/c11
> code which only expects 0,1,2 values to appear (and does
> not use _Float16 at all), but it seems to be the better
> fit for hardware with half precision instructions.

Maybe this indicates that -fexcess-precision=standard, whether explicit or 
implies by a -std option, must cause FLT_EVAL_METHOD=0 for such hardware, 
and some new -fexcess-precision= option is needed to select 
FLT_EVAL_METHOD=16 (say -fexcess-precision=16, with no expectation that 
most numeric -fexcess-precision= arguments are supported except where a 
target hook says they are or where they are the default FLT_EVAL_METHOD 
value).  Then -std=c2x, if C2X integrates TS 18661-3, might not imply the 
value 0 for such hardware, because the value 16 would also be OK as a 
standard value in that case.  This can be part of the design issues to 
address alongside those I mentioned in 
<https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01899.html>.

-- 
Joseph S. Myers
joseph@codesourcery.com