This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Revamp fortran array types
On 08/20/2009 09:21 AM, Paolo Bonzini wrote:
> On 08/19/2009 07:59 PM, Toon Moene wrote:
>>>>
>>>> DIMENSION A(10)
>>>> A = 10.0
>>>> CALL SUB(A,A)
>>>> END
>>>> SUBROUTINE SUB(A,B)
>>>> REAL, INTENT(IN) :: A(:), B(:)
>>>
>>> What happens if you replace the last line with
>>>
>>> REAL, INTENT(IN) :: A(:)
>>> REAL, INTENT(OUT) :: B(:)
>>>
>> The following code is perfectly OK:
>>
>> Fascinating. I *think* that - as long as you do not actually write to B
>> - you're in the clear.
And I agree - based on the standard (see quote below) - it should be valid.
>
> I think even B(2) = A(1) would be fine. Or even
>
> B(2:N:2) = A(1:N-1:2)
I do not think so - at least not according to the Fortran standard:
"12.5.2.13 Restrictions on entities associated with dummy arguments"
"Action that affects the value of the entity or any subobject of it
shall be taken only through the dummy argument unless ... the actual
argument is a target"
Thus you are changing "B" if you are writing to "A" - you do not do this
at the same location in memory but you do it for the same variable.
Whether one is fine in practice is another question. The problem is only
that when compilers get smarter, things which are wrong but simply
"worked" before, stop doing so. For this example, what could go wrong
you already wrote:
> Long term, if the vectorizer supported this kind of masking it may get
> it into trouble because of aliasing.
>
Tobias