This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] PR opt/13037: "Same" BIVs in update_giv_derive

The following patch is my proposed fix to PR optimization/13037 which
is an incorrect code generation problem in GCC's RTL optimizers.  The
test case in the PR fails on the 3.3 branch, but has become latent on
mainline [Many thanks again to Janis for tracking this down].

Unfortunately, the GCSE reference in the bugzilla title and in the
identified patch on mainline are red herrings.  The real problem is
the handling of the redundant stores in GCC's induction variable
handling code.  Subtle changes to GCSE can avoid/expose these duplicate
stores to induction variables, which while valid as RTL, can cause
potential problems during "loop".

Duplicate or redundant writes to pseudos holding basic induction
variables are identified by loop's biv discovery code, which sets
their biv->same field.  This flag is honored in most IV manipulation
code, but unfortunately one of the places that isn't is the routine
"update_giv_derive".  By ignoring biv->same, this function, which
calculated how GIVs are derived from BIVs, believes that the BIV
has been updated more times than it really has.  In the test case
below, this leads to the destination pointer GIV being initialised
to a value one iteration too early.

The relatively simple fix is to ignore duplicate/redudant biv insns
as we do in other passes.

The following patch has been tested on i686-pc-linux-gnu against
both mainline and gcc-3_3-branch, with complete bootstraps, all
languages except treelang (and Ada on the 3.3 branch), and regression
tested with a top-level "make -k check" with no new failures.  The
new testcase derived from the PR passes on 3.3 with this patch but
fails without.

Ok for mainline and the 3.3 branch?

Many thanks in advance,

2003-12-06  Roger Sayle  <>

	PR optimization/13037
	* loop.c (update_giv_derive): Ignore redundant sets of a biv when
	calculating how to derive a giv from a biv.

	* g77.f-torture/execute/13037.f: New test case.

Index: loop.c
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.476
diff -c -3 -p -r1.476 loop.c
*** loop.c	21 Nov 2003 06:52:23 -0000	1.476
--- loop.c	6 Dec 2003 06:56:44 -0000
*************** update_giv_derive (const struct loop *lo
*** 6095,6100 ****
--- 6095,6104 ----
        if (GET_CODE (p) == CODE_LABEL || GET_CODE (p) == JUMP_INSN
  	  || biv->insn == p)
+ 	  /* Skip if location is the same as a previous one.  */
+ 	  if (biv->same)
+ 	    continue;
  	  for (giv = bl->giv; giv; giv = giv->next_iv)
  	      /* If cant_derive is already true, there is no point in

c      PR optimization/13037
c      Contributed by Kirill Smelkov
c      bug symptom: zeta(kkzc) seems to reference to zeta(kkzc-1) instead
c      with gcc-3.2.2 it is OK, so it is a regression.
      subroutine bug1(expnt)
      implicit none

      double precision zeta
      common /bug1_area/zeta(3)

      double precision expnt(3)

      integer k, kkzc

      do k=1,3
         kkzc = kkzc + 1
         zeta(kkzc) = expnt(k)

c     the following line activates the bug
      call bug1_activator(kkzc)

c     dummy subroutine
      subroutine bug1_activator(inum)
      implicit none
      integer inum

c     test driver
      program test_bug1
      implicit none

      double precision zeta
      common /bug1_area/zeta(3)

      double precision expnt(3)

      zeta(1) = 0.0d0
      zeta(2) = 0.0d0
      zeta(3) = 0.0d0

      expnt(1) = 1.0d0
      expnt(2) = 2.0d0
      expnt(3) = 3.0d0

      call bug1(expnt)
      if ((zeta(1).ne.1) .or. (zeta(2).ne.2) .or. (zeta(3).ne.3)) then
        call abort


Roger Sayle,                         E-mail:
OpenEye Scientific Software,         WWW:
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]