Thanks for the quick action Paul - I hope the fix goes through A small correction in the example problem though: there is no begin program statement in your snippet. It still fails, as is, due to the ICE, but I think if you make the fix this example program will still fail to compile. A simple `program main` before `use mod` should do the trick.
Regards, Chris On Tue, Feb 7, 2017 at 5:06 PM, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > This bug generates an ICE because the symbol for dummy 'n' in the > specification expression for the result of 'fun1' is not the same as > the symbol in the formal arglist. For some reason that I have been > unable to uncover, this false dummy is associated with a unique > symtree. The odd thing is that the dump of the parse tree for the > failing module procedure case is identical to that where the interface > is explcitely reproduced in the submodule. The cause of the ICE is > that the false dummy has no backend_decl as it should. > > This patch hits the problem directly on the head by using the > backend_decl from the symbol in the namespace of the formal arglist, > as described in the comment in the patch. If it is deemed to be more > hygenic, the chunk of code can be lifted out and deposited in a > separate function. > > Bootstraps and regtests on FC23/x86_64 - OK for trunk? > > Cheers > > Paul > > 2017-02-07 Paul Thomas <pa...@gcc.gnu.org> > > PR fortran/79344 > * trans-decl.c (gfc_get_symbol_decl): If a dummy apparently has > a null backend_decl, look for a replacement symbol in the > namespace of the 1st formal argument and use its backend_decl. > > 2017-02-07 Paul Thomas <pa...@gcc.gnu.org> > > PR fortran/79344 > * gfortran.dg/submodule_23.f90: New test.
