Re: transfer_array_intrinsic testcase failures (was Re: transfer_array_intrinsic failures)

[dominiq at lps dot ens dot fr (Dominique Dhumieres)]

Paul,

g95 returns:

In file transfer_array_intrinsic_1.f90:89

     ch(3:2:-1) = transfer (y, ch, 3)
			  1
Error: Array assignment at (1) has different shape on dimension 1 (2/3)
In file transfer_array_intrinsic_1.f90:95

     ch(1:2) = transfer (y, ch, 3)
		       1
Error: Array assignment at (1) has different shape on dimension 1 (2/3)
In file transfer_array_intrinsic_1.f90:38

     cmp = transfer (z, cmp, 1) * 8.0
				 1
Error: Array assignment at (1) has different shape on dimension 1 (2/1)

You wrote:

> Yes, I know - I believe that ifort is wrong on the errors and right on
> the warning.  The standard is quite clear that transfer effects a
> bit-wise copy that either fills the destination or exhausts the
> source/size combination.  From my reading of that, conformity of shapes
> is not required.  If I have read wrong, please let me know and I will
> implement a conforming version.  A an aside, whatever the standard says,
> it strikes me that transfer is useful for being able to do just that sort
> of thing; it might be dangerous but memcpy's always are.

In the 2003 draft I read:

> 13.7.121 TRANSFER (SOURCE, MOLD [, SIZE])
> 
> Description.  Returns a result with a physical representation identical
> to that of SOURCE but interpreted with the type and type parameters of
> MOLD.
> 
> Class.  Transformational function.
> 
> Arguments.
> 
> SOURCE may be of any type.  It may be a scalar or an array.
> 
> MOLD may be of any type.  It may be a scalar or an array.  If it is a
> variable, it need not be defined.
> 
> SIZE (optional) shall be scalar and of type integer.  The corresponding
> actual argument shall not be an optional dummy argument.
> 
> Result Characteristics.  The result is of the same type and type
> parameters as MOLD.
> 
> Case (i): If MOLD is a scalar and SIZE is absent, the result is a scalar.
> 
> Case (ii): If MOLD is an array and SIZE is absent, the result is an array
> and of rank one.  Its size is as small as possible such that its physical
> representation is not shorter than that of SOURCE.
> 
> Case (iii): If SIZE is present, the result is an array of rank one and
> size SIZE.
> 
> Result Value.  If the physical representation of the result has the same
> length as that of SOURCE, the physical representation of the result is
> that of SOURCE. If the physical representation of the result is longer
> than that of SOURCE, the physical representation of the leading part is
> that of SOURCE and the remainder is processor dependent.  If the physical
> representation of the result is shorter than that of SOURCE, the physical
> representation of the result is the leading part of SOURCE. If D and E
> are scalar variables such that the physical representation of D is as
> long as or longer than that of E, the value of TRANSFER (TRANSFER (E, D),
> E) shall be the value of E. IF D is an array and E is an array of rank
> one, the value of TRANSFER (TRANSFER (E, D), E, SIZE (E)) shall be the
> value of E.

I think you misread it at "that either fills the destination": 
my reading is that if MOLD is a scalar or SIZE is present, TRANSFER 
returns an array of rank one and size equal to 
(SIZE(MOLD)*KIND(SOURCE)+KIND(MOLD)-1)/KIND(MOLD) in the former case 
(assuming KIND() to be proportional to the storage requirement) and
SIZE in the latter one. Then the result is written to the destination
and for that, the destination must be of rank one and size SIZE(TRANSFER())
to be conforming, see Richard Maine's comment at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/706ab41fcc06ee15/4194372a96685b99#4194372a96685b99

I think ifort, g95, xlf, ... are right to detect an error. For instance

     cmp (1:1) = transfer (z, cmp, 1) * 8.0

works. For the two other tests, I think you cannot expect:
"! Check that too large a value of size is cut off." as implemented.

Dominique