Re: [patch, fortran] Fix a TRANSFER folding bug, rework Hollerith handling.

[Brooks Moses <brooks dot moses at codesourcery dot com>]

At 01:53 AM 5/28/2007, Tobias Burnus wrote:
> :REVIEWMAIL:
>
> Brooks Moses wrote:
> > The problem, fundamentally, is this: If one takes a strict
> > interpretation of the Fortran standard, the following little program
> > is required to return 42:
> >
> >   logical, parameter :: A = TRANSFER (4, .true.)
> >   integer, parameter :: I = TRANSFER (A, 0)
> >   write(*,*) I
> 42 or 4? I think you mean 4. That is at least what older gfortrans,
> ifort and sunf95 give; g95 returns "1", NAG f95 ICEs.
> Current gfortran seems to use A = <integer> % 2 and returns thus 0.

Yes, right, that should return 4 -- that was a typo.

> I think one could argue that I == 0, 1 and 4 are all valid according to
> the Fortran standard. Nonetheless, returning 4 as your patch, gfortran
> 4.1 and 4.2, ifort and sunf95 is arguably most useful. In addition, the
> new implementation is much cleaner.

Thanks!

The other case that this patch gets right and is rather more difficult to 
argue against in the standard, is

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

> > This currently does not work with the constant-folding.  The transfer
> > to A determines that 4 is nonzero, and thus A has a logical value of
> > true, and the gfc_expr that is created merely stores that value.
> > Then, the constant-folding to I knows that a value of true is stored
> > as if it has an integer value of 1, and the output is 1.
> 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?

> > My next project will be folding BOZ-literals into this system, I
> > think; that will be useful to handle how Fortran 2003 does
> > REAL(Z'FFF0') and that kind of mess -- and, coincidentally, give us a
> > very small start on Fortran 2008.  :)
> For REAL(Z'FFF0') we need also a good warning system in place. Using the
> vendor extension for BOZ, this is interpreted as INTEGER BOZ which is
> then converted to real rather than as REAL BOZ. (Cf. PR29471)

Right -- I definitely remember the discussions we had about that!

> Besides, I thought the next project would be PR 31972 (ICE with
> transferring Hollerith).

Good point; I'll get to that this afternoon.  That one's simple enough not 
to be a "project", though.  :)

> > Regression-tested on powerpc-apple-darwin8.9.0.  Ok for trunk?
> Ok (builds also under x86_64-unknown-linux-gnu)

Thanks you.

Committed, with the testcase renamed to transfer_simplify_4.f90 to avoid a 
name-clash with the recently-added transfer_simplify_3.

- Brooks