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

[dominiq at lps dot ens dot fr]

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