https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122206
--- Comment #11 from kargls at comcast dot net --- (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? The problem shows up on x86_64-*-freebsd without the -m32 option. See comment #2. With -fdump-tree-original one sees, val1 = simple_function (iarg1, arg2, arg3, arg4); <-- Value attribute here. val2 = simple_function (&iarg1, &arg2, &arg3, &arg4); <-- Value attribute stripped. Harald was much quicker than I (thanks Harald!) in finding a patch. I found that gfortrans calls gfc_conv_procedure_call() for each function reference and the attributes are set as one expects. I did not have a chance to walk through gfc_conv_procedure_call() to see whether the path through the procedure was different.
