Hi Andre,
The next lines, immediately after the chunk in trans-decl.cc are:
/* Dummy variables should already have been created. */
gcc_assert (sym->backend_decl);
It's taken care of :-)
Thanks for the review.
Paul
On Wed, 22 Jan 2025 at 14:21, Andre Vehreschild <[email protected]> wrote:
> Hi Paul,
>
> the patch looks reasonable to me. Ok for mainline.
>
> Just a side-thought: Could it be possible, that the for-loop in trans-decl
> does
> not find the result? Would an assert after the loop at least give a hint,
> where
> something went wrong? That's just from reading the code, so if you think
> that
> can not happen, feel free to commit w/o the assert.
>
> Regards,
> Andre
>
> On Wed, 22 Jan 2025 14:03:15 +0000
> Paul Richard Thomas <[email protected]> wrote:
>
> > Hi All,
> >
> > This patch fixes a double ICE arising from confusion between the dummy
> > symbol arising from a module function/subroutine interface and the module
> > procedure itself. In both cases, use of the name is unambiguous, as
> > explained in the ChangeLog. The testcase contains both the original and
> the
> > variant in comment 1.
> >
> > Regtests OK with FC41/x86_64 - OK for mainline and later backporting?
> >
> > Paul
> >
> > Fortran: Regression- fix ICE at fortran/trans-decl.c:1575 [PR96087]
> >
> > 2025-01-22 Paul Thomas <[email protected]>
> >
> > gcc/fortran
> > PR fortran/96087
> > * trans-decl.cc (gfc_get_symbol_decl): If a dummy is missing a
> > backend decl, it is likely that it has come from a module proc
> > interface. Look for the formal symbol by name in the containing
> > proc and use its backend decl.
> > * trans-expr.cc (gfc_apply_interface_mapping_to_expr): For the
> > same reason, match the name, rather than the symbol address to
> > perform the mapping.
> >
> > gcc/testsuite/
> > PR fortran/96087
> > * gfortran.dg/pr96087.f90: New test.
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>
