Implement C _FloatN, _FloatNx types [version 6]
Joseph Myers
joseph@codesourcery.com
Fri Aug 19 16:24:00 GMT 2016
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
More information about the Gcc-patches
mailing list