Re: PR87689, PowerPC64 ELFv2 function parameter passing violation
On Thu, Feb 14, 2019 at 10:32:50AM +0100, Richard Biener wrote: > On Wed, Feb 13, 2019 at 7:59 AM Alan Modra 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
Re: PR87689, PowerPC64 ELFv2 function parameter passing violation
On Thu, Feb 14, 2019 at 10:32:50AM +0100, Richard Biener wrote: > On Wed, Feb 13, 2019 at 7:59 AM Alan Modra 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
On Wed, Feb 13, 2019 at 7:59 AM Alan Modra 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 (_so_far_v); > > > -- > Alan Modra > Australia Development Lab, IBM
PR87689, PowerPC64 ELFv2 function parameter passing violation
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 (_so_far_v); -- Alan Modra Australia Development Lab, IBM
