* PR87689, PowerPC64 ELFv2 function parameter passing violation
@ 2019-02-13 6:59 Alan Modra
2019-02-14 9:33 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2019-02-13 6:59 UTC (permalink / raw)
To: gcc-patches; +Cc: Segher Boessenkool
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PR87689, PowerPC64 ELFv2 function parameter passing violation
2019-02-13 6:59 PR87689, PowerPC64 ELFv2 function parameter passing violation Alan Modra
@ 2019-02-14 9:33 ` Richard Biener
2019-02-14 12:37 ` Alan Modra
2019-02-14 15:47 ` Segher Boessenkool
0 siblings, 2 replies; 4+ messages in thread
From: Richard Biener @ 2019-02-14 9:33 UTC (permalink / raw)
To: Alan Modra; +Cc: GCC Patches, Segher Boessenkool
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PR87689, PowerPC64 ELFv2 function parameter passing violation
2019-02-14 9:33 ` Richard Biener
@ 2019-02-14 12:37 ` Alan Modra
2019-02-14 15:47 ` Segher Boessenkool
1 sibling, 0 replies; 4+ messages in thread
From: Alan Modra @ 2019-02-14 12:37 UTC (permalink / raw)
To: Richard Biener; +Cc: GCC Patches, 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.
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PR87689, PowerPC64 ELFv2 function parameter passing violation
2019-02-14 9:33 ` Richard Biener
2019-02-14 12:37 ` Alan Modra
@ 2019-02-14 15:47 ` Segher Boessenkool
1 sibling, 0 replies; 4+ messages in thread
From: Segher Boessenkool @ 2019-02-14 15:47 UTC (permalink / raw)
To: Richard Biener; +Cc: Alan Modra, GCC Patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-02-14 15:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-13 6:59 PR87689, PowerPC64 ELFv2 function parameter passing violation Alan Modra
2019-02-14 9:33 ` Richard Biener
2019-02-14 12:37 ` Alan Modra
2019-02-14 15:47 ` Segher Boessenkool
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).