PR87689, PowerPC64 ELFv2 function parameter passing violation

PR87689, PowerPC64 ELFv2 function parameter passing violation

[Alan Modra]

Covers for a generic fortran bug.  The effect is that we'll needlessly
waste 64 bytes of stack space on some calls, but I don't see any
simple and fully correct patch in generic code.  Bootstrapped and
regression tested powerpc64le-linux.  OK mainline and branches?

	PR target/87689
	* config/rs6000/rs6000.c (rs6000_function_parms_need_stack): Cope
	with fortran function decls that lack all args.

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 31256a4da8d..288b7606b5e 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -12325,6 +12325,13 @@ rs6000_function_parms_need_stack (tree fun, bool incoming)
   if ((!incoming && !prototype_p (fntype)) || stdarg_p (fntype))
     return true;
 
+  /* 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;
+
   INIT_CUMULATIVE_INCOMING_ARGS (args_so_far_v, fntype, NULL_RTX);
   args_so_far = pack_cumulative_args (&args_so_far_v);
 

-- 
Alan Modra
Australia Development Lab, IBM

Re: PR87689, PowerPC64 ELFv2 function parameter passing violation

[Richard Biener]

On Wed, Feb 13, 2019 at 7:59 AM Alan Modra <amodra@gmail.com> wrote:
>
> Covers for a generic fortran bug.  The effect is that we'll needlessly
> waste 64 bytes of stack space on some calls, but I don't see any
> simple and fully correct patch in generic code.  Bootstrapped and
> regression tested powerpc64le-linux.  OK mainline and branches?

This looks very wrong to me ;)  It won't work when compiling with -flto
for example.

The frontend needs to be properly fixed.

Richard.

>         PR target/87689
>         * config/rs6000/rs6000.c (rs6000_function_parms_need_stack): Cope
>         with fortran function decls that lack all args.
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 31256a4da8d..288b7606b5e 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -12325,6 +12325,13 @@ rs6000_function_parms_need_stack (tree fun, bool incoming)
>    if ((!incoming && !prototype_p (fntype)) || stdarg_p (fntype))
>      return true;
>
> +  /* 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;
> +
>    INIT_CUMULATIVE_INCOMING_ARGS (args_so_far_v, fntype, NULL_RTX);
>    args_so_far = pack_cumulative_args (&args_so_far_v);
>
>
> --
> Alan Modra
> Australia Development Lab, IBM

Re: PR87689, PowerPC64 ELFv2 function parameter passing violation

[Alan Modra]

On Thu, Feb 14, 2019 at 10:32:50AM +0100, Richard Biener wrote:
> On Wed, Feb 13, 2019 at 7:59 AM Alan Modra <amodra@gmail.com> wrote:
> >
> > Covers for a generic fortran bug.  The effect is that we'll needlessly
> > waste 64 bytes of stack space on some calls, but I don't see any
> > simple and fully correct patch in generic code.  Bootstrapped and
> > regression tested powerpc64le-linux.  OK mainline and branches?
> 
> This looks very wrong to me ;)  It won't work when compiling with -flto
> for example.

Blah.  Nothing looks right to me. :)  That patch was really me giving
up on the bug (and hoping I'd found a suitable hack that could be
applied to gcc-8 and gcc-7).

> The frontend needs to be properly fixed.

You'll notice I didn't assign myself to the bug..

-- 
Alan Modra
Australia Development Lab, IBM

Re: PR87689, PowerPC64 ELFv2 function parameter passing violation

[Segher Boessenkool]

On Thu, Feb 14, 2019 at 10:32:50AM +0100, Richard Biener wrote:
> On Wed, Feb 13, 2019 at 7:59 AM Alan Modra <amodra@gmail.com> wrote:
> >
> > Covers for a generic fortran bug.  The effect is that we'll needlessly
> > waste 64 bytes of stack space on some calls, but I don't see any
> > simple and fully correct patch in generic code.  Bootstrapped and
> > regression tested powerpc64le-linux.  OK mainline and branches?
> 
> This looks very wrong to me ;)  It won't work when compiling with -flto
> for example.

Yeah, that is a show-stopper.

> The frontend needs to be properly fixed.

Sure, but until that happens our target suffers while it seems to work for
everyone else.  This won't be the first or last time a target needs an ugly
workaround, and this one is in target code even ;-)


Segher