------- Comment #24 from sgk at troutmask dot apl dot washington dot edu
2008-10-31 14:37 -------
Subject: Re: gfortran error and ICE at automatic type conversion with transfer
intrinsic
On Fri, Oct 31, 2008 at 01:10:21PM -0000, burnus at gcc dot gnu dot org wrote:
>
>
> ------- Comment #23 from burnus at gcc dot gnu dot org 2008-10-31 13:10
> -------
> > > in any case NaN can be unambiguously converted from one real/complex to
> > > another real/complex kind.
> >
> > I disagree with the last sentence since there in not a single (or dual if
> > you
> > take into account signaling NaN's) NaN entity, but a whole class of them.
>
> Still IEEE 754-2008 defines what a signalling/quiet NaN is; with regards to a
> programmer, "NaN" is "NaN" and the exact bit pattern should not matter; and
> for
> qNaN and sNaN - if you don't have IEEE trapping turned on, you effectively
> have
> a quiet NaN in either case. Independent of the bit pattern "x /= x" is always
> true if x is NaN and if x is NaN, y = x*5 will assign "NaN" to y. Thus I don't
> see any ambiguity.
>
First, gfortran (especially the constant folding) doesn't
follow IEEE754 for NaN. AFAIK, there is no distinction
between qNaN and sNaN.
That being said, from Draft 1.2.5 of the revised standard,
section 8.2.3 states:
Conversion of a quiet NaN to a floating-point format of the same
or a different radix that does not allow the payload to be preserved,
should return a quiet NaN that should provide some language-defined
diagnostic information.
It appears that gfortran's error message is providing "some
language-defined diagnostic information." I'll also note that
the diagnostic information tells you how to disable the range
checking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
