[Patch, Fortran] PR fortran/37425: Finish type-bound operators

[Tobias Schlüter]

Hi Daniel,

Daniel Kraft wrote:
> Tobias Burnus wrote:
>> Daniel Kraft wrote:
>>> * What's the usage of EXEC_ASSIGN_CALL instead of EXEC_CALL?
>> It was introduced with PR25746 - and there with the patch "[Patch,
>> fortran] PR25746 - operator assignment dependency checking",
>> http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00296.html.
>>
>> That patch introduces the distinction in gfc_trans_call whether a
>> dependency checking should be done (EXEC_ASSIGN_CALL) or not (EXEC_CALL).
> 
> Hm, I still don't get the difference between EXEC_ASSIGN_CALL and 
> EXEC_CALL.  Shouldn't writing the ASSIGNMENT(=) operator and calling the 
> assignment-procedure directly in the code be exactly equivalent?  This 
> seems not to be the case with a special EXEC_ASSIGN_CALL...

think of
   B(2:n) = B(1:n-1)

The compiler has to implement this as
   do i = n, 2, -1
      b(i) = b(i-1)
   end do
(or something equivalent, say copying via a temporary) instead of
   do i = 2, n
      b(i) = b(i-1)
   end do

EXEC_ASSIGN_CALL adds the necessary dependency checking for this.  If f 
is the subroutine that is implementing this assignment, then calling
   f(b(2:n), b(1:n-1))
directly doesn't do the dependency checks.  That is the difference 
between EXEC_ASSIGN_CALL and EXEC_CALL.  Note that the comment in front 
of gfc_conv_elemental_dependencies() and the function's name is 
misleading, as it has nothing to do with elemental subroutines that take 
care of assignments, the same check is needed for non-elemental 
subroutines.  Paul, can you confirm this last thing I said?

So, I think you could construct a testcase that breaks if you use 
EXEC_CALL instead EXEC_ASSIGN_CALL.  This should also go into the testsuite.

Hope this helps,
- Tobi