------- Comment #12 from dominiq at lps dot ens dot fr 2008-10-28 17:51 -------
(In reply to comment #8)
> 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.
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
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?
> 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!
I also find very weird to assign transfer(integer, real) to an integer. I don't
see the logic of this construct: what is it supposed to do?
Note also that the behavior of gfortran is not consistent, as shown by the
following test:
[ibook-dhum] f90/bug% cat > pr37930_db_1.f90
r = transfer(-1,1.0)
i = r
print *, i
end
[ibook-dhum] f90/bug% gfc pr37930_db_1.f90
[ibook-dhum] f90/bug% a.out
-2147483648
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
