https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #17 from Alan Modra <amodra at gmail dot com> ---
> On platforms where varargs have a different calling
> signature from normal functions, this would be an ABI change.
True, but in C terms, gfortran is currently doing this:
void f (char *res, int reslen);
..
f (res, 20, &c, &i1, &i2, &i3, &i4, &i5, &i6);
That's why I said we have "lying prototypes".
The patch in comment #12 changes things to
void f (char *res, int reslen, ...);
..
f (res, 20, &c, &i1, &i2, &i3, &i4, &i5, &i6);
Which at least makes the prototype and call compatible in that translation
unit. We have ABI violations in both cases as neither prototype matches the
actual function definition. Yes, my patch is just a hack, but..
> It would probably make more sense to build the decl from the call
> itself.
This would require major surgery, I think. Another option would be to pass
info to the backend that the call is really not prototyped despite the presence
of those "hidden" args.
For now, I'm going to post a backend patch for this problem, in
rs6000_function_parms_need_stack:
/* FIXME: Fortran arg lists can contain hidden parms, fooling
prototype_p into saying the function is prototyped when in fact
the number and type of args is unknown. See PR 87689. */
if (!incoming && (strcmp (lang_hooks.name, "GNU F77") == 0
|| lang_GNU_Fortran ()))
return true;
