------- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2008-10-28 18:40 -------
Subject: Re: gfortran error and ICE at automatic type conversion with transfer
intrinsic
On Tue, Oct 28, 2008 at 05:51:06PM -0000, dominiq at lps dot ens dot fr wrote:
>
> > i = NaN is an assignment not a bitwise copy. This isn't platform
> > dependent nor option dependent. You simply can't assign a NaN to
> > an INTEGER.
>
> Before the assignment, there is an attempt to convert the real 'NaN' to a
> default integer.
i = 1.23456 --> i = 1
i = 3.14149 --> i = 3
i = NaN --> i = what goes here?
> This conversion is platform dependent. Now consider the following code:
>
> i = -huge(1.0)
> print *, i, -huge(1.0)
> end
>
> which compiles without problem with the option -fno-range-check and gives at
As soon as you used the -fno-range-check option, you are telling
gfortran to violate the standard. gfortran can do whatever it
pleases.
troutmask:kargl[213] gfc -o z -fno-range-check -fdump-parse-tree j.f90
ASSIGN MAIN__:i 340282346638528859811704183484516925440
WRITE UNIT=6 FMT=-1
TRANSFER MAIN__:i
TRANSFER 3.40282347e38
DT_END
Looks like the well-known integer wrap around issue.
What is mod(34028..., 2^32)? Could also be 2^31 - 1; too lazy
to investigate any farther.
> run time:
>
> 0 -3.40282347E+38
>
> Is -3.40282347E+38 more valid than NaN or -Inf? Or is that the extension has
> not been defined for the later real values?
What happens without -fno-range-check?
> > In thinking about transfer(-1,1.0), this may also be invalid
> > because the standard forbids calling an intrinsic procedure
> > if it will return a result outside the representable range of
> > the return type. There is probably some argument on whether
> > NaN is this range.
>
> My point of view has always been that +/-Inf and NaN's should abort the
> executable, but I seems alone to think so!
See -ffpe-trap option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
