Re: [Patch, fortran] PR42736 - [4.3/4.4/4.5 Regression] Wrong-code with allocatable or pointer components in elemental functions

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Tobias,

On Wed, Jan 20, 2010 at 12:02 AM, Tobias Burnus <burnus@net-b.de> wrote:
> On 18.01.2010 16:08, Paul Richard Thomas wrote:
>> Bootstrapped and regtested on FC9/x86_64 - OK for trunk, 4.4 and 4.3?
>>
>> 2010-01-18 ?Paul Thomas ?<pault@gcc.gnu.org>
>>
>> ? ? ? PR fortran/42736
>> ? ? ? * dependency.c (possible_aliasing_types): New function.
>> ? ? ? (possible_aliasing): New function.
>> ? ? ? (gfc_check_dependency): Call the above to tighten up checking
>> ? ? ? of potential aliasing with derived types.
>>
>> 2010-01-18 ?Paul Thomas ?<pault@gcc.gnu.org>
>>
>> ? ? ? PR fortran/42736
>> ? ? ? * gfortran.dg/dependency_25.f90 : New test.
>>
>
> + ? if (expr1->expr_type != EXPR_VARIABLE
> + ? ? ? || expr1->expr_type != EXPR_VARIABLE)
> + ? ? return 0;
>
>
> You surely didn't want to check the same condition twice ;-)

Ah, yes.  A touch of copy, paste and....   thanks.

> Additionally, I wonder whether one cannot construct a test case with a
> (pointer-returning) function where the dependency is not 0. (Actually, I
> think the function is only called for variables - the LHS must be
> assignable and the RHS needs also be a variable [switch case in caller];
> if so, I would prefer an assert.)

This is already controlled by the callers of this function.  In fact,
I wonder if the if statement was necessary at all.

>
> Regarding your ts1 test, I wonder in how far one also should check for
> attr.target. Currently, if expr1 is not a pointer/does not contain a
> pointer component, the result of possible_aliasing is always 0; I have
> the feeling that this is (potentially) wrong if expr1...->attr.target == 1.

I gave some thought to check for expr1 being a target.  However, the
call to possible aliasing with expr1 <=> expr2 was intended to deal
with that and the more general case, where aliasing is occuring
because the symbol represents dummy argument.

I was going to find a case that still fails today.  I am sure that
they exist; in which case, the scalarizer still needs fixing or...
well, I have some other ideas.

Cheers

Paul