[29/32] Remove global call sets: sched-deps.c

[Christophe Lyon]

On Fri, 4 Oct 2019 at 16:35, Richard Sandiford <richard.sandiford@arm.com>
wrote:

> Christophe Lyon <christophe.lyon@linaro.org> writes:
> > On Mon, 30 Sep 2019 at 00:20, Jeff Law <law@redhat.com> wrote:
> >
> >     On 9/11/19 1:17 PM, Richard Sandiford wrote:
> >     > This is a straight replacement of an existing "full or partial"
> >     > call-clobber check.
> >     >
> >     >
> >     > 2019-09-11  Richard Sandiford  <richard.sandiford@arm.com>
> >     >
> >     > gcc/
> >     >       * sched-deps.c (deps_analyze_insn): Use the ABI of the target
> >     >       function to test whether a register is fully or partly
> clobbered.
> >     OK
> >     jeff
> >
> >
> > Hi Richard,
> >
> > My testing shows regressions on arm after you applied this patch
> (r276335):
> > For instance on arm-none-linux-gnueabi
> > --with-mode arm
> > --with-cpu cortex-a9
> > FAIL:  gcc.dg/strlenopt-18g.c execution test
> >
> > If you force -march=armv5t via RUNTESTFLAGS, there's an additional
> failure:
> > FAIL: gcc.dg/strlenopt-19.c execution test
> >
> > In fortran, I see different sets of regressions depending on arm vs
> thumb mode.
> > target arm-none-linux-gnueabi
> > --with-mode arm
> > --with-cpu cortex-a9
> > I get these new FAILs:
> >     gfortran.dg/char4_iunit_1.f03   -O0  execution test
> >     gfortran.dg/char4_iunit_1.f03   -O1  execution test
> >     gfortran.dg/char4_iunit_1.f03   -O2  execution test
> >     gfortran.dg/char4_iunit_1.f03   -O3 -fomit-frame-pointer
> -funroll-loops
> > -fpeel-loops -ftracer -finline-functions  execution test
> >     gfortran.dg/char4_iunit_1.f03   -O3 -g  execution test
> >     gfortran.dg/char4_iunit_1.f03   -Os  execution test
> >     gfortran.dg/namelist_16.f90   -O0  execution test
> >     gfortran.dg/namelist_16.f90   -O1  execution test
> >     gfortran.dg/namelist_16.f90   -O2  execution test
> >     gfortran.dg/namelist_16.f90   -O3 -fomit-frame-pointer -funroll-loops
> > -fpeel-loops -ftracer -finline-functions  execution test
> >     gfortran.dg/namelist_16.f90   -O3 -g  execution test
> >     gfortran.dg/namelist_16.f90   -Os  execution test
> >     gfortran.dg/namelist_95.f90   -O0  execution test
> >     gfortran.dg/namelist_95.f90   -O1  execution test
> >     gfortran.dg/namelist_95.f90   -O2  execution test
> >     gfortran.dg/namelist_95.f90   -O3 -fomit-frame-pointer -funroll-loops
> > -fpeel-loops -ftracer -finline-functions  execution test
> >     gfortran.dg/namelist_95.f90   -O3 -g  execution test
> >     gfortran.dg/namelist_95.f90   -Os  execution test
> >     gfortran.dg/real_const_3.f90   -O0  execution test
> >     gfortran.dg/real_const_3.f90   -O1  execution test
> >     gfortran.dg/real_const_3.f90   -O2  execution test
> >     gfortran.dg/real_const_3.f90   -O3 -fomit-frame-pointer
> -funroll-loops
> > -fpeel-loops -ftracer -finline-functions  execution test
> >     gfortran.dg/real_const_3.f90   -O3 -g  execution test
> >     gfortran.dg/real_const_3.f90   -Os  execution test
> >
> >
> > When defaulting to thumb:
> > target arm-none-linux-gnueabi
> > --with-mode thumb
> > --with-cpu cortex-a9
> > I get these new FAILs:
> >     gfortran.dg/f2003_io_5.f03   -O0  execution test
> >     gfortran.dg/f2003_io_5.f03   -O1  execution test
> >     gfortran.dg/f2003_io_5.f03   -O2  execution test
> >     gfortran.dg/f2003_io_5.f03   -O3 -fomit-frame-pointer -funroll-loops
> > -fpeel-loops -ftracer -finline-functions  execution test
> >     gfortran.dg/f2003_io_5.f03   -O3 -g  execution test
> >     gfortran.dg/f2003_io_5.f03   -Os  execution test
> >     gfortran.dg/real_const_3.f90   -O0  execution test
> >     gfortran.dg/real_const_3.f90   -O1  execution test
> >     gfortran.dg/real_const_3.f90   -O2  execution test
> >     gfortran.dg/real_const_3.f90   -O3 -fomit-frame-pointer
> -funroll-loops
> > -fpeel-loops -ftracer -finline-functions  execution test
> >     gfortran.dg/real_const_3.f90   -O3 -g  execution test
> >     gfortran.dg/real_const_3.f90   -Os  execution test
> >
> > This is the most recent validation result I have so far, so maybe you
> already
> > fixed the problem?
>
> This sounds very like
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00170.html
> Let me know if you see any remaining failures after that though.
>
>
I looks OK, now.
Note that r276489 fixed the strlenopt regressions, while the fortran
regressions
seem to have been fixed between r276457 and  r276488 (that is, just before
the above patch).

Thanks,

Christophe

Thanks,
> Richard
>