------- Comment #9 from dominiq at lps dot ens dot fr 2008-09-29 20:25 ------- Although I am not familiar with the gfortran code, gfc_array_size (mold, &tmp)I think the reason why gfortran.dg/transfer_array_intrinsic_4.f90 fails with the patch in comment #6, is because gfc_array_size (mold, &tmp) looks at the size of mold, while the relevant part of the TRANSFER definition is:
If SIZE is absent but MOLD is an array (of any size or shape), the result is a one-dimensional array of the minimum length needed to contain the entirety of the bitwise representation of SOURCE. So I think tmp should contain (number_of_bytes_in_SOURCE+size_in_bytes_of_a_MOLD_element-1)/size_in_bytes_of_a_MOLD_element. Note that it would be interesting to test the code for [1_1], [1_2], [1_8], and -fdefault-integer-8 to rule out side effects. BTW I think the code in comment #0 is valid for both statement order: if 'real x' is before TRANSFER, it value is not defined, but not necessary to get the size; if 'real x' is after TRANSFER, x is implicitely defined as real and I think it is legal to confirm it by the 'real x' statement. At least the following code real :: y=epsilon(x) real :: x print *, y end is accepted by gfortran, ifort, and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680