Reported by Jakub. "gfortran -O2 -fwhole-file" generates a variadic call to bar_. (The decl of the procedure itself is OK.) Expected: a) With -fwhole-file, the actual declaration should be used. b) As Fortran does not support variadic calls at all, there should be never variatic calls be generated. (variadic calls are those whose prototype ends in C with "..."; when generating the argument list with build_function_type_list the function is always non-variadic (cf. also build_varargs_function_type_list) - if one generates the argument list manually, the last argument should be VOID_TYPE.) * * * subroutine bar (a, n) integer :: n, a(*) end subroutine bar subroutine foo (b, n) integer :: n, b(n) n = 6 call bar (b, 5) b(1:5) = 0 end subroutine foo * * * How to test (thanks to Jakub for the list of options): a) x86_64 (for non floating points): Assembler has xorl %eax, %eax before the call (i.e. the variadic function has no floating-point arguments) b) In a debugger: b var-tracking.c:8357 if insn->code == CALL_INSN (which is if (INSN_P (insn)) in vt_initialize) -- and then: debug_rtx (insn)
We generate a variadic prototype for the decl when calling bar because we try to generate it anew, instead of finding the toplevel decl already existing. This is (again) the multiple decls issue. (Well, we could also fix this issue by rebuilding a complete new decl that has the right argument types, but frankly, we might as well fix the multiple decls issue.)
Created attachment 20899 [details] Possible patch OK, maybe I came out too strong in my last comment. It is possible to get the front-end to construct a real argument types list from the arguments list of the external call, as is done in the patch attached. Maybe it's worth putting in, I don't really know. It's a bit of a hack, but at least it does work (and it regtests on x86_64-linux).
(In reply to comment #2) > It is possible to get the front-end to construct a real argument types list > from the arguments list of the external call, as is done in the patch attached. I think doing so is the proper way - the question is whether one should already do it earlier such that in resolve.c one can give a diagnostic for external foo call foo(3.0) call foo(4) ! <<< error, inconsistent interface end Cf. PR 40976.) In any case, (re)constructing the interface from the call is sensible.
Cf. PR 45304 for a partial fix.
The #c2 patch is problematic, because build_function_type shares function types, so setting TYPE_ARG_TYPES on that I'm afraid will affect all functions with (...) arguments and the same return type. So, the arglist needs to be passed down to gfc_get_function_type or wherever build_function_type is called. Furthermore, this doesn't help the case of functions that have no arguments (when we build_function_decl instead gfc_get_extern_function_decl, yet sym->formal is NULL or gfc_get_extern_function_decl for call noargsfn () ).
See also PR 33097 and PR 40976. Try also the program at http://gcc.gnu.org/ml/fortran/2010-05/msg00330.html to make sure it still works.
We now use the backend decl if there is one. And with PR87689 fixed, we no longer use variadic calls. The xorl is no longer there. Hence, closing as FIXED.