This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Implement C _FloatN, _FloatNx types [version 6]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: James Greenhalgh <james dot greenhalgh at arm dot com>, <nd at arm dot com>, <gcc-patches at gcc dot gnu dot org>, <fortran at gcc dot gnu dot org>, <jason at redhat dot com>, <richard dot earnshaw at arm dot com>, <nickc at redhat dot com>, <ramana dot radhakrishnan at arm dot com>, <marcus dot shawcroft at arm dot com>, <dje dot gcc at gmail dot com>, <segher at kernel dot crashing dot org>, <meissner at linux dot vnet dot ibm dot com>, <murphyp at linux dot vnet dot ibm dot com>
- Date: Fri, 19 Aug 2016 16:23:55 +0000
- Subject: Re: Implement C _FloatN, _FloatNx types [version 6]
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1606211202040.4526@digraph.polyomino.org.uk> <alpine.DEB.2.20.1606211738200.31330@digraph.polyomino.org.uk> <alpine.DEB.2.20.1606231418120.21240@digraph.polyomino.org.uk> <alpine.DEB.2.20.1606271720270.7438@digraph.polyomino.org.uk> <alpine.DEB.2.20.1607191347340.9265@digraph.polyomino.org.uk> <alpine.DEB.2.20.1607222158330.22448@digraph.polyomino.org.uk> <20160817154244.GA39270@arm.com> <alpine.DEB.2.20.1608171641000.7156@digraph.polyomino.org.uk> <alpine.DEB.2.20.1608172015080.27199@digraph.polyomino.org.uk> <57B72592.5060509@arm.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