[PATCH, PR94769] fortran/io.c: Fix use of uninitialized variable num

[Richard Biener]

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  <stefansf@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
>