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 <paul.richard.tho...@gmail.com> 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 <pa...@gcc.gnu.org>
>
> 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
