On Tue, Apr 28, 2020 at 3:23 PM Jakub Jelinek via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Tue, Apr 28, 2020 at 01:53:07PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > gcc/fortran/ChangeLog:
> >
> > 2020-04-28 Stefan Schulze Frielinghaus <stefa...@linux.ibm.com>
> >
> > PR fortran/94769
> > * io.c (check_io_constraints): Initialize local variable num.
> > ---
> > gcc/fortran/io.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
> > index e066666e01d..4526f729d1d 100644
> > --- a/gcc/fortran/io.c
> > +++ b/gcc/fortran/io.c
> > @@ -3840,7 +3840,7 @@ if (condition) \
> >
> > if (dt->asynchronous)
> > {
> > - int num;
> > + int num = 2;
> > static const char * asynchronous[] = { "YES", "NO", NULL };
>
> Just nitpicking, wouldn't -1 be more usual value?
> And, I think there should be an assertion that it didn't remain -1 after the
> call, above
> /* For "YES", mark related symbols as asynchronous. */
> do
> gcc_checking (num != -1);
> or so.
>
> Note, the reason why this triggers only on s390x is the vastly different
> inlining parameters the target uses, that causes a lot of headaches
> everywhere.
... which also do not get adjusted when the global settings do.
s390 param_max_inline_insns_auto is now (for >= z13) more than
five times the default one! param_inline_min_speedup is also
waaaay off (2 vs. 30)
But it's always the target maintainers call ... (note that -finline-functions
is now enabled at -O2 so this will _vastly_ increase binary size there).
Honza, I guess you didn't consider targets playing with those defaults?
A better approach than setting a different absolute value per target
is to scale the default with a factor.
Richard.
> Jakub
>
