This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Implement C _FloatN, _FloatNx types [version 6]
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: <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:28:18 +0100
- Subject: Re: Implement C _FloatN, _FloatNx types [version 6]
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- 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>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.