[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic

["sgk at troutmask dot apl dot washington dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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