(j3.2006) COPY mode of argument association

Robert Corbett robert.corbett
Thu Dec 17 21:39:31 EST 2015


On 12/17/15 15:40, Van Snyder wrote:
> On Thu, 2015-12-17 at 21:07 +0000, Lionel, Steve wrote:
>> >  "The solution was to pass the location of the child vertex back as a
>> >  function argument.  I hope processors don't calculate the address of the
>> >  function result and pass that as a hidden argument for the function to use
>> >  to store its result value."
>> >  
>> >  Why, yes, they do. On the implementations I am familiar with, this happens
>> >  if the result is of a type other than what the ABI says should be returned
>> >  in registers. For example, returning any array or CHARACTER value would be
>> >  done with a hidden argument containing an address of temporary storage
>> >  computed by the caller.
>> >  
>> >  I didn't fully understand the problem statement, but it seemed to me that
>> >  pointers might be an appropriate solution.
> Here's the recursive function reference:
>
> QTM_Trees%Q(root)%son(f) = Add_QTM_Vertex_To_Tree ( 4*QID+f )
>
> Add_QTM_Vertex_To_Tree is an internal function.  It can access QTM_Trees
> by host association.  If QTM_Trees%Q runs out of space, it's reallocated
> twice as big, the old one copied into the new, and then deleted.  So the
> QTM_Trees%Q(root) in effect when Add_QTM_Vertex_To_Tree is invoked might
> be a different one when it returns.
>
> I understand that if the result type of Add_QTM_Vertex_To_Tree isn't one
> that can be returned in a register that the processor will compute an
> address and tell Add_QTM_Vertex_To_Tree where to store its result.  I
> just hope it's not the address of QTM_Trees%Q(root)%son(f).
>
> The reference used to be
>
> call Add_QTM_Vertex_To_Tree ( QTM_Trees%Q(root)%son(f), 4*QID+f )
>
> That didn't work because if Add_QTM_Vertex_To_Tree reallocated QTM_Trees
> %Q it violated the "no change to the actual argument except through the
> dummy argument" dictum.

The assignment statement violates a restriction in the standard.  I know of
implementations for which it will fail.

The restriction that the statement violates is presented in paragraph 2 of
Subclause 7.1.4 of 15-007r2.  An earlier form of the restriction appeared
in FORTRAN 77.  I did not find the restriction in FORTRAN 66, but I did not
do a careful search.

The desired effect of the statement can be obtained by splitting the
assignment statement.  First, assign the result of the function to a scalar
variable, then assign the scalar variable to variable on the left-hand side
of the original assignment.  A good optimizer should eliminate the new
variable and the extra assignment.

Bob Corbett



More information about the J3 mailing list