[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

["dominiq at lps dot ens dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #13 from dominiq at lps dot ens dot fr  2008-10-03 22:23 -------
> Happily, I have come to the conclusion that the code is invalid no matter which
> order the declarations come in;
> ....
> (a) a restricted expression or
> (b) a variable whose properties inquired about are not
> the TRANSFER (x, [1]) argument is manifestly not consistent with (b) and should
> fail by (a) with exactly the g95 message.

After having knotted my neurones, I agree with that: size(transfer(x, [1])) is
not a "restricted expression".

> I will make it so.

Good!

> In fact the ICE is precisely due to the argument not being a restricted
> expression, since the size of x and its kind are unavailable to the caller and
> the interfacing cannot be made to work.  This is why restricted expressions
> only permit dummy, host- or use-associated or common variables and why my
> attempts to evaluate the transfer are failing.

However I disagree with this part of the analysis:

size(transfer(real(1.0,kind(x)), [1_1])) is a "restricted expression" (happily
accepted by gfortran) that uses exactly the same information as
size(transfer(x, [1])) as shown by the following code:

program main
  print *, foo()
  print *, size(transfer(real(1.0,kind(x)), [1_1])),&
           size(transfer(x, [1_1]))
  if (size(foo()) /= kind(x)) call abort()
contains
  function foo()
    integer foo(size(transfer(real(1.0,kind(x)), [1_1])))
    real x
    foo=transfer(real(1.0,kind(x)), [1_1])
  end function
end program

giving on intel machines (without the patch in comment #6)

           0           0        -128          63
           4           4

(with the patch the second line is 4 1) or

           0           0           0           0           0           0       
 -16          63
           8           8

when compiled with -fdefault-real-8. On ppc I get

          63        -128           0           0
           4           4

and

          63         -16           0           0           0           0       
   0           0
           8           8


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680