Bug 24034 - [4.1 regression] Regrename: Inconsistency Failure
Summary: [4.1 regression] Regrename: Inconsistency Failure
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.1.0
: P5 normal
Target Milestone: 4.1.0
Assignee: Andreas Krebbel
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: ice-on-valid-code, patch
Depends on:
Blocks: 15023
  Show dependency treegraph
 
Reported: 2005-09-23 13:48 UTC by Andreas Krebbel
Modified: 2005-11-09 12:24 UTC (History)
2 users (show)

See Also:
Host: s390x-ibm-linux
Target: s390x-ibm-linux
Build: s390x-ibm-linux
Known to work:
Known to fail:
Last reconfirmed: 2005-11-01 15:12:27


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Krebbel 2005-09-23 13:48:57 UTC
gcc -v:

Configured with: /build/gcc-4.1/configure --prefix=/build/gcc-4.1-install
--enable-shared --with-system-zlib --enable-threads=posix --enable-__cxa_atexit
--enable-checking=release --program-suffix=-4.1 --disable-multilib
Thread model: posix
gcc version 4.1.0 20050920 (experimental)

Testcase reduced from 920501-4.c:

Compile with -O3 -funroll-loops

foo ()
{
  int r0[8186];
  int r1[2];
  int i, m, n, m_max;
  int f;
  double fm, ft;
  while (1)
    {
      if (m % 4 == 2)
        ++m;
      if (m_max != 0 && m > m_max)
        break;
      while (n % f == 0)
        {
          while ((ft != 0) && (ft < fm))
            {
              r1[i] = 0;
            }
          while (r0[i] != 0 && r1[i] != 0)
            {
              if (r0[i] < r1[i])
                {
                }
            }
        }
    }
}

global alloc puts the uninitialized variables n, f, m_max into r1.

Because global alloc does not consider quantities for uninitialized variables
conflicting with others r1 is also used locally in bb6, bb10 and in bb20.

37.greg:

(insn 265 201 203 20 (set (reg:SI 1 %r1 [93])
        (const_int 0 [0x0])) 51 {*movsi_zarch} (nil)
    (expr_list:REG_EQUIV (const_int 0 [0x0])
        (nil)))

(insn:QI 203 265 204 20 (parallel [
            (set (reg:CCL3 33 %cc)
                (compare:CCL3 (reg:SI 1 %r1 [93])
                    (reg:SI 2 %r2 [89])))
            (clobber (reg:SI 1 %r1 [93]))
        ])

Updated life info in 41.csa says that r1 is dead at begin and life at end of bb20.

Regrename then decides to rename r1 to r5 and performs a local life update.
Because r1 is not set in bb20 anymore and it is live at bb end it can be
concluded that r1 has to be live at bb start. But this differs from the
state before and the assertion in verify_local_live_at_start ist triggered.

44.rnreg:

Basic block 20:
Closing chain %r1 at insn 203 (terminate_dead)
Register %r1 (1): 265 [GENERAL_REGS] 203 [GENERAL_REGS] 203 [GENERAL_REGS]
Register %r1 in insn 203, renamed as %r5

live_at_start mismatch in bb 20, aborting
New:

first = 0x80531570 current = 0x80531570 indx = 0
        0x80531570 next = (nil) prev = (nil) indx = 0
                bits = { 0 1 2 3 4 13 15 16 }
Old:
;; basic block 20, loop depth 1, count 0
;; prev block 19, next block 21
;; pred:       18 [79.0%]  19 [100.0%]  (fallthru)
;; succ:       10 [3.5%]  (loop_exit) 21 [96.5%]  (fallthru)
;; Registers live at start:  0 [%r0] 2 [%r2] 3 [%r3] 4 [%r4] 13 [%r13] 15 [%r15]
16 [%f0
]
...
(insn 265 201 203 20 (set (reg:SI 5 %r5 [93])
        (const_int 0 [0x0])) 51 {*movsi_zarch} (nil)
    (expr_list:REG_EQUIV (const_int 0 [0x0])
        (nil)))

(insn:QI 203 265 204 20 (parallel [
            (set (reg:CCL3 33 %cc)
                (compare:CCL3 (reg:SI 5 %r5 [93])
                    (reg:SI 2 %r2 [89])))
            (clobber (reg:SI 5 %r5 [93]))
        ])

The problem was already discussed on gcc mailing list:
http://gcc.gnu.org/ml/gcc/2005-08/msg00448.html

A possible solution could be performing a global live update instead of a local
which would not trigger the assertion. Additionally for correct live info we
should call the make_accurate_live_analysis which is used in global alloc
afterwards.
Comment 1 Andreas Krebbel 2005-10-21 08:04:39 UTC
This is fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00803.html

Please review.
Comment 2 Andreas Krebbel 2005-11-09 12:24:06 UTC
Patch committed:

http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00387.html