[Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

[Harald Anlauf]

Hi Tobias,

Am 07.03.22 um 15:01 schrieb Tobias Burnus:
> The problem is that inside the main program,
>    y = f(z)
> where the the result of z is
>    type(t) :: z(size(x%a))
> and 'x' is a dummy argument.
>
> 'x' looses the attr.dummy in gfc_add_interface_mapping
> and this leads to an additional indirect ref in
> gfc_maybe_dereference_var - but after the first indirect
> ref, TREE_TYPE is alread a RECORD_TYPE ...
>
> The simple fix is to simply punt when the argument
> is not a pointer or reference.
>
> This patch additionally fixes a comment in
> conv_parent_component_references.

LGTM.  Regarding the commit message, there should be a period
at the end of

 >        (gfc_maybe_dereference_var): Avoid derefereing a nonpointer


I think there are other PRs which profit from this fix.
Can you please have a look at PR99585, and in particular
the link in comment#0?  ;-)

> Those parts are obvious. The only potentially risky
> change is the comparison change from a name-wise comparison
> to a pointer-based comparison. I think it is fine and the
> testsuite did not find any issue, but you prefer, I can
> also exclude it.

I was thinking about this, too.  But your change will prevent
running into trouble in the (unlikely?) case c being a NULL pointer.

> OK for mainline? How about GCC 10/11 backports?
> (I think leaving out the last change, it should be very safe to do.)

OK, as this is both an ICE-on-valid and a regression.

Thanks for the patch!

Harald

> Tobias
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
> Registergericht München, HRB 106955