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

Reply via email to