On 02/08/2017 08:00 AM, Paul Richard Thomas wrote:
Dear All,The attached rework of the patch functions in the same way as yesterday's but is based in resolve.c rather than trans-decl.c. It looks to me to be by far cleaner. Bootstraps and regtests on FC23/x86_64 - OK for trunk? Cheers Paul 2017-02-08 Paul Thomas <pa...@gcc.gnu.org> PR fortran/79344 * resolve.c (fixup_unique_dummy): New function. (gfc_resolve_expr): Call it for dummy variables with a unique symtree name. 2017-02-08 Paul Thomas <pa...@gcc.gnu.org> PR fortran/79344 * gfortran.dg/submodule_23.f90: New test. On 7 February 2017 at 16:06, 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?
Yes OK. Jerry
