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