[PATCH] PR71275 ira.c bb_loop_depth

Alan Modra amodra@gmail.com
Wed Jun 15 06:02:00 GMT 2016


On Wed, Jun 15, 2016 at 11:00:22AM +0930, Alan Modra wrote:
> On Tue, Jun 14, 2016 at 09:26:19AM -0700, H.J. Lu wrote:
> > On Thu, May 26, 2016 at 4:02 AM, Alan Modra <amodra@gmail.com> wrote:
> > > This fixes lack of bb_loop_depth info in some of the early parts of
> > > ira, which has been the case for quite some time.  All active branches
> > > return 0 from bb_loop_depth() in update_equiv_regs, but whether that
> > > actually causes mis-optimization anywhere but trunk is yet to be
> > > determined.
> > >
> > > I played a little with trying to consolidate this loop_optimizer_init
> > > call with one that occurs a little later, but ran into ICEs.  (We now
> > > have four calls to loop_optimizer_init in ira.c.)
> > >
> > > Bootstrapped and regression tested powerpc64le-linux and x86_64-linux.
> > > OK to apply?
> > >
> > >         PR rtl-optimization/71275
> > >         * ira.c (ira): Call loop_optimizer_init to set up bb_loop_depth
> > >         for update_equiv_regs and combine_and_move_insns.
> > >
> > 
> > This caused:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71531

So, not guilty.  Or at least only guilty of exposing another bug.
You have a problem with parameter passing.

cat > pass.c <<EOF
extern int __attribute__ ((pure)) f1 (int, int);

int main (void)
{
  if (f1 (1, 0) != 2)
    __builtin_abort ();
  if (f1 (1, 1) != 0)
    __builtin_abort ();
  return 0;
}
EOF
cat > pass2.c <<EOF
int __attribute__ ((pure)) f2 (int);

int __attribute__ ((pure)) f1 (int a, int b)
{
  int x = a;
  if (b)
    x = -a;
  return f2 (x + 1);
}
EOF
cat > pass3.c <<EOF
int __attribute__ ((pure)) f2 (int a)
{
  return a;
}
EOF
gcc -m32 -march=corei7 -mtune=slm -O2 pass.c pass2.c pass3.c
./a.out
Aborted
gcc -O2 pass.c pass2.c pass3.c
./a.out

> I have an x86 ABI question.  Is it correct according to the ABI that
> parameter passing stack slots always have the same value on function
> exit as they had on entry?
> 
> Between these two calls to _gfortran_string_verify,
>   if (verify(c4, "A", back = .true.) .ne. 3) call abort
>   if (verify(c4, "AB") .ne. 0) call abort
> it seems that gfortran is assuming that parameters passed on the stack
> are unchanged.
> 
> _gfortran_string_verify is a C function, declared as follows in
> libgfortran/intrinsics/string_intrinsics_inc.c:
> gfc_charlen_type
> string_verify (gfc_charlen_type slen, const CHARTYPE *str,
> 	       gfc_charlen_type setlen, const CHARTYPE *set,
> 	       GFC_LOGICAL_4 back)
> 
> This function happens to modify the stack slot for "slen" to -1 when
> "back" is true.
> 
> -- 
> Alan Modra
> Australia Development Lab, IBM

-- 
Alan Modra
Australia Development Lab, IBM



More information about the Gcc-patches mailing list