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 jos...@codesourcery.com
