------- Comment #13 from paul dot richard dot thomas at gmail dot com
2010-06-22 04:36 -------
Subject: Re: gfortran generates wrong results due to wrong
ABI in function with array return
Dear Tobias,
Thanks for looking through the patch.
> Does use_assoc also include host-associated variables - it should for this
> check. (I have not checked.)
No, it doesn't - I will add such a check.
>
> Additionally allowed without temporary:
> sym->attr.dummy && sym->attr.intent == INTENT_OUT
> as
> "If a dummy argument has INTENT (OUT), the actual argument becomes
> undefined at the time the association is established"
> thus also any access via any method to that variable is undefined - and thus
> invalid.
>
> I think that the LHS is a dummy argument is a very common case and thus it
> makes sense to optimize for INTENT(OUT).
>
Hmmm! I'll have to think about this business of dummies and their
intent. Perhaps you could give me an example, where this causes
aliasing?
>
> + && expr2->value.function.esym
> + && !expr2->value.function.esym->attr.contained)
>
> Doesn't this not also unnecessarily prohibit
> contains
> subroutine a()
> dimension :: x(4)
> x = f()
> end subroutine
> function f()
> as "f" is contained (in the same namespace as "a"? Or is this not set for the
> "sym" as available in the namespace of "a"?
The check for host association of x is needed to suppress this case
from producing a temporary.
>
>
> Otherwise, the patch looks OK.
>
>> + /* TODO a function that could correctly be declared PURE but is not
>> + could do with returning false as well. */
>
> (Well said, but not easily to be implemented. Actually, that could be a weaker
> check as pure routines may not do I/O (on file units) or use (ERROR) STOP and
> the argument INTENT(IN)/VALUE constraints do not matter either.)
Indeed. I'll have a think about this, whilst I am about it. It could
be done in resolve.c in parallel with the checks for purity. I'll
make it a separate patch, though.
Thanks
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
