https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122206
--- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #7) > (In reply to anlauf from comment #6) > > Debugging the reduced testcase suggests that the interface gets clobbered > > in gfc_get_formal_from_actual_arglist along a weird path. > > > > Untested fix: > > > > diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc > > index 26645b0f7f6..7e08ff1581c 100644 > > --- a/gcc/fortran/trans-types.cc > > +++ b/gcc/fortran/trans-types.cc > > @@ -3441,6 +3441,7 @@ gfc_get_function_type (gfc_symbol * sym, > > gfc_actual_arglist *actual_args, > > } > > } > > if (sym->backend_decl == error_mark_node && actual_args != NULL > > + && sym->ts.interface == NULL > > && sym->formal == NULL && (sym->attr.proc == PROC_EXTERNAL > > || sym->attr.proc == PROC_UNKNOWN)) > > gfc_get_formal_from_actual_arglist (sym, actual_args); > > I managed to test this here on my reduced test case. It bothers me that the > problem only shows itself with -m32. Is there some sort of memory alignment > issue going on here? It appears so. Maybe I did reduce the number of arguments too much so that we do not see any crash because all arguments are passed in registers and not on the stack. With -m32 there are fewer registers. Other arches might behave differently. But the essential point is that on the second call the formal arguments have the wrong attributes (e.g. no VALUE).
