[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-fortran
Subject:    Re: [patch, fortran] Fix a TRANSFER folding bug, rework    Hollerith handling.
From:       Brooks Moses <brooks.moses () codesourcery ! com>
Date:       2007-05-28 22:23:09
Message-ID: 4.3.1.2.20070528151012.02d23248 () cits1 ! stanford ! edu
[Download RAW message or body]

At 03:00 PM 5/28/2007, Tobias Burnus wrote:
>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.

Possibly.  However, default integer, default real, and default logical are 
all defined as taking up one numeric storage unit, and can all be 
storage-associated with each other; see F2003 16.4.3.1, item 1.  Thus they 
need to at least be padded out to the same number of bits.

Even if you argue that the "size of the physical representation" is less 
than the amount of space they take up including padding, though, there's an 
array form of the double-transfer that's required to work anyway.

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

Yes, but that's because double-precision reals are twice the size of a 
default logical.  Try it with single-precision; F2003 13.7.121 specifically 
and explicitly requires that it work in that case.

Also try the array form, if you want double-precision:

   real(kind(0d0), parameter, r(1) = &
     transfer(transfer(sqrt(2d0), (/ .true. /) ), (/ 0d0 /), 1)

That one is also explicitly required to work, regardless of the relative 
sizes of the "physical representation" of the arguments.

If those don't work, file bug reports.  :)

- Brooks


[prev in list] [next in list] [prev in thread] [next in thread]