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

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

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