PR 35681: Correct handling of "expressions" with ELEMENTAL subroutines

[Daniel Kraft]

Hi Paul,

Paul Richard Thomas wrote:
>>>> Currently there's already logic to handle temporaries (although for the
>>>> INTENT(OUT) arguments) if required for ELEMENTAL calls
>>>> (trans-stmt.c:gfc_conv_elemental_dependencies) and I tried to study the
>>>> code
>>>> there, but unfortunatelly am not really an expert about trans-time
>>>> scalarization and all those ss/se things.
>>> The testcase in this PR never exercises this bit of code because the
>>> resolved_symbol for MVBITS never gets formal arguments.  A very good
>>> start would be to fix this.  In addition, you would have to detect
>>> that MVBITS is being handled by trans-call in order to call
>>> gfc_conv_elemental_dependencies.  This is because MVBITS is the
>>> exception to the rule about allowing arguments to an elemental
>>> subroutine that can alias.
>> I'm not sure what gfc_conv_elemental_dependencies is really for, and I know
>> it does not get called; but I hoped to find guidance on how I can do my own
>> temporaries, but didn't really find what I was looking for (at least, didn't
>> quite understand every detail so it would be useful).
> 
> It is specifically for the case of interface assignment and ensures
> that a temporary is written if there is a dependency between the lhs
> (INTENT(OUT)) and the rhs (INTENT(IN)).  It can, however, be hijacked
> for MVBITS.

Yes, I've seen that, too, but didn't think about it when writing; 
however, I agree that we could probably re-use it for the MVBITS case, 
as written (somewhere, I don't think above...).  Let's see :)

> Indeed, this
> 
>   integer, dimension (2) :: xx, yy
>   xx = [1,2]
>   call foo ((xx([2,1])), yy)
>   yy = bar ((xx([2,1])))
> contains
>   elemental subroutine foo (a1, a2)
>     integer, intent(in) :: a1
>     integer, intent(out) :: a2
>     a2 = 2*a1
>   end subroutine
>   elemental integer function bar (a1)
>      integer, intent(in) :: a1
>      bar = 2*a1
>   end function
> end
> 
> does not produce a temporary for the subroutine or the function
> call...... but then neither does g95.  That said, g95 does the right
> thing with the original testcase with mvbits!
> 
> I have to confess that I am now confused about the effect of
> parentheses on elemental procedure arguments.
> 
> I think that it's one for clf.

That was my original point; the temporary is created, but inside the 
scalarization loop where the expression and thus the parentheses get 
evaluated.  I would suppose that there's really need for an array 
temporary (in the copy case I'm looking at, where there's a dependency 
between the arguments otherwise), but I'm not completely sure if the 
standard requires it.  So if you can't confirm it is needed, I'll ask on 
clf.

For this one I was trying to create temporaries before the scalarization 
loop, much like gfc_conv_elemental_dependencies but for EXPR_OPs, not 
EXPR_VARIABLE.

Writing this, it comes to mind, what does gfortran do for something like:

CALL copy (thisReturnsAnArray (), someArr)

with ELEMENTAL copy?  Wouldn't *this* have to create a temporary for the 
result out of the scalarization loop?  Haven't time to try now, 
unfortunatelly...  I'll look at it later, and maybe this can be some 
starting point?

>> What's about, for instance for a numeric vector x, "x + 0"?  Wouldn't this
>> also require a temporary just as parentheses would?  But my main problem was
>> that I didn't even get the parentheses temporary work, because the way it is
>> done in gfc_conv_elemental_dependencies relies on an ss_info-structure (or
>> something like that) which is there for EXPR_VARIABLE's but seems to be
>> missing for EXPR_OP's.  But maybe this can be fixed?  But this once again
>> would probably be a quite intrusive change.
> 
> This would not ordinarily need a temporary, except for MVBITS when
> there is a dependency.

Shouldn't it work for other ELEMENTAL subroutine calls, too, even if 
there are dependencies, at least *if* such a "dummy expression" is 
created instead of passing the same variable twice?

Cheers,
Daniel

-- 
Done:  Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou