This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch, fortran] Fix a TRANSFER folding bug, rework Hollerith handling.
Brooks Moses wrote:
> integer, parameter :: I = TRANSFER(TRANSFER(42, .true.), 0)
>
> The standard explicitly requires that sort of double transfer to
> correctly round-trip the initial value. I tried arguing on
> comp.lang.fortran that the inner TRANSFER function was illegal, but
> Richard Maine was pretty sure that it wasn't. So eventually I was
> convinced. :)
I really wonder how this should work if true is implemented as one bit.
(I think there is nothing in the standard which requires that that
integer(kind(0)) and logical(kind(.true.)) need to have internally the
same number of bits. At least the following does not work with any of my
compilers:
real(kind(0d0)), parameter :: r =
transfer(transfer(sqrt(2d0),.true.), 0d0
the result is never sqrt(2d0) nor do I expect it to be. In any case, if
one do a round-trip, it is in any case good if it works.
And I'm too lazy to right through
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b29957a2f57fec25/85bd722ca7f27727
>> Hmm, why do I get "0" and not "1" with an unpatched gfortran? I get 1
>> only for odd numbers.
> That is interesting. Is that coming from the constant-folder, or the
> runtime version?
I don't remember, I think it was the constant-folder version. I tried to
reproduce it with some older gfortran builds, but I failed. Currently, I
get for all gfortran versions I tried the right result.
Tobias