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: 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: Thu, 1 Sep 2016 15:40:10 +0000
- Subject: Re: Implement C _FloatN, _FloatNx types [version 6]
- Authentication-results: sourceware.org; auth=none
- References: <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> <alpine.DEB.2.20.1608191617480.6408@digraph.polyomino.org.uk> <20160831165830.GA4541@arm.com> <alpine.DEB.2.20.1608311707190.6827@digraph.polyomino.org.uk> <57C80852.1020203@arm.com>
On Thu, 1 Sep 2016, Szabolcs Nagy wrote:
> it seems that the FLT_EVAL_METHOD change in TS 18661 was a
> bad decision: existing code have to be modified to conform
> to the new semantics. this situation could have been avoided
> by introducing new macros or only changing behaviour when
> the user requested it via __STDC_WANT_IEC_60559_TYPES_EXT__
> (consistently with all other library changes..).
You could always raise the issue directly with WG14, since TS 18661 is
supposed to be compatible with C11 (cf the issue I raised about whether
the formula for DECIMAL_DIG in C11 is normatively required or a minimum).
Now a minimal fix for such an issue (interpreted as a DR against C11
rather than against TS 18661-3) to make the definition of FLT_EVAL_METHOD
extensible would be to remove the word "negative" in "All other negative
values for FLT_EVAL_METHOD characterize implementation-defined behavior.",
so making it more like FLT_ROUNDS. Which would allow the value 16 to be
used in existing standards modes, but not avoid the need to update
existing code to handle it. But you might prefer an interpretation as a
DR against TS 18661-3 where the FLT_EVAL_METHOD definition does not have
to reflect the new types unless __STDC_WANT_IEC_60559_TYPES_EXT__ is
defined accordingly (and maybe for consistency DEC_EVAL_METHOD only has to
reflect TS 18661-2 decimal types, not those from 18661-3, unless
__STDC_WANT_IEC_60559_TYPES_EXT__ is defined).
I expect glibc will be defining __STDC_WANT_IEC_60559_TYPES_EXT__ soon
anyway (in its <float.h> wrapper to get FLT128_* definitions from there
where possible) so would still need adapting to be optimal with _Float16
compiler support.
--
Joseph S. Myers
joseph@codesourcery.com