[Bug c/31944] New: Endless loop while building a 64-bit 2.6.20 kernel

[Bug c/31944] New: Endless loop while building a 64-bit 2.6.20 kernel

[aurelien at aurel32 dot net]

The file fs/ocfs2/dlm/dlmmaster.c from the 2.6.20 kernel triggers an endless
loop in gcc 4.1 built for the hppa64-linux-gnu target.

It occurs at -O2, but not at -O1 or -O0. Also specifying -fno-cse-follow-jumps
workaround the problem.


Thanks to Randolph Chung we have a reduced testcase:

struct bug { int type; };

static void stuck(struct bug *mle, void *res)
{
 if (mle->type == 1) {
  if (res == 0) asm volatile("nop");
 } 
 else if (mle->type == 0) {
  if (res == 0) {
    asm volatile("nop" : : "i" (0)); 
  }
 }
}

void foo(void) { stuck(0, 0); }
void bar(void) { stuck(0, 0); }


And some infos about the compiler used:

Using built-in specs.
Target: hppa64-linux-gnu
Configured with: ../src/configure --enable-languages=c --prefix=/usr
--libexecdir=/usr/lib --disable-shared --disable-nls --disable-threads
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libssp
--with-as=/usr/bin/hppa64-linux-gnu-as --with-ld=/usr/bin/hppa64-linux-gnu-ld
--includedir=/usr/hppa64-linux-gnu/include --host=hppa-linux-gnu
--build=hppa-linux-gnu --target=hppa64-linux-gnu
Thread model: single
gcc version 4.1.3 20070429 (prerelease) (Debian 4.1.2-6)


-- 
           Summary: Endless loop while building a 64-bit 2.6.20 kernel
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aurelien at aurel32 dot net
 GCC build triplet: hppa1.1-linux-gnu
  GCC host triplet: hppa1.1-linux-gnu
GCC target triplet: hppa64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[aurelien at aurel32 dot net]

------- Comment #1 from aurelien at aurel32 dot net  2007-05-16 11:08 -------
The problem is also present in gcc HEAD (SVN from today) built as a
cross-compiler on x86_64-linux-gnu.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

------- Comment #2 from danglin at gcc dot gnu dot org  2007-05-17 03:55 -------
Test case also fails to compile on hppa64-hp-hpux11.11.  Compiler
hangs in cse1 pass, apparently doing garbage collection.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

------- Comment #3 from danglin at gcc dot gnu dot org  2007-05-20 17:38 -------
My last comment about this being a GC problem was wrong.  Here's a
backtrace from a compiler containing debug symbols:

(gdb) bt
#0  0x4000000000c5a274 in get_cse_reg_info (regno=66)
    at ../../gcc/gcc/cse.c:847
#1  0x4000000000c5d31c in invalidate (x=0x800003fffec89d00,
    full_mode=VOIDmode) at ../../gcc/gcc/cse.c:1727
#2  0x4000000000c5cf18 in flush_hash_table () at ../../gcc/gcc/cse.c:1661
#3  0x4000000000c69d28 in cse_insn (insn=0x800003fffeda8f00, libcall_insn=0x0)
    at ../../gcc/gcc/cse.c:5341
#4  0x4000000000c6d480 in cse_extended_basic_block (
    ebb_data=0x800003fffeff12e0) at ../../gcc/gcc/cse.c:6104
#5  0x4000000000c6df74 in cse_main (f=0x800003fffec93ec0, nregs=74)
    at ../../gcc/gcc/cse.c:6296
#6  0x4000000000c706f0 in rest_of_handle_cse () at ../../gcc/gcc/cse.c:7032
#7  0x400000000064a7e0 in execute_one_pass (pass=0x8000000100004d70)
    at ../../gcc/gcc/passes.c:1065
#8  0x400000000064aaa8 in execute_pass_list (pass=0x8000000100004d70)
    at ../../gcc/gcc/passes.c:1117
#9  0x400000000064aae8 in execute_pass_list (pass=0x8000000100002610)
    at ../../gcc/gcc/passes.c:1118
#10 0x4000000000852070 in tree_rest_of_compilation (fndecl=0x800003fffec79300)
    at ../../gcc/gcc/tree-optimize.c:406
#11 0x400000000021f844 in c_expand_body (fndecl=0x42fec89d00)
    at ../../gcc/gcc/c-common.c:4345
#12 0x4000000000b3d09c in cgraph_expand_function (node=0x800003fffec79400)
---Type <return> to continue, or q <return> to quit---q
 at .Quit
(gdb) p debug_rtx (0x800003fffec89d00)
(reg:DI 66 [ D.1605 ])
(gdb) frame 2
#2  0x4000000000c5cf18 in flush_hash_table () at ../../gcc/gcc/cse.c:1661
1661              invalidate (p->exp, VOIDmode);
(gdb) p i
$3 = 3
(gdb) p p
$4 = (struct table_elt *) 0x8000000100102d88
(gdb) p table[3]
$5 = (struct table_elt *) 0x8000000100102d88

static void
flush_hash_table (void)
{
  int i;
  struct table_elt *p;

  for (i = 0; i < HASH_SIZE; i++)
    for (p = table[i]; p; p = table[i])
      {
        /* Note that invalidate can remove elements
           after P in the current hash chain.  */
        if (REG_P (p->exp))
          invalidate (p->exp, VOIDmode);
        else
          remove_from_table (p, i);
      }
}

So, it looks like we are stuck in flush_hash_table.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

------- Comment #4 from danglin at gcc dot gnu dot org  2007-05-20 18:15 -------
For reference, this is the rtl at the point of the hang:

(gdb) p debug_rtx_list (get_insns (), 30)
(note 6 0 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 3 6 4 2 pr31944.c:4 (set (reg/v/f:DI 68 [ mle ])
        (reg:DI 26 %r26 [ mle ])) 124 {*pa.md:4569} (nil)
    (nil))

(insn 4 3 5 2 pr31944.c:4 (set (reg/v/f:DI 69 [ res ])
        (reg:DI 25 %r25 [ res ])) 124 {*pa.md:4569} (nil)
    (nil))

(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)

(insn 8 5 9 2 pr31944.c:5 (set (reg:SI 70 [ <variable>.type ])
        (mem/s:SI (reg/v/f:DI 68 [ mle ]) [3 <variable>.type+0 S4 A32])) 71
{*pa.md:2568} (nil)
    (nil))

(insn 9 8 10 2 pr31944.c:5 (set (reg:DI 66 [ D.1605 ])
        (sign_extend:DI (reg:SI 70 [ <variable>.type ]))) 143 {extendsidi2}
(nil)
    (nil))

(jump_insn 10 9 11 2 pr31944.c:5 (set (pc)
        (if_then_else (ne (subreg/s:SI (reg:DI 66 [ D.1605 ]) 4)
                (const_int 1 [0x1]))
            (label_ref 18)
            (pc))) 46 {*pa.md:1768} (nil)
    (expr_list:REG_BR_PROB (const_int 6900 [0x1af4])
        (nil)))

(note 11 10 12 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 12 11 13 3 pr31944.c:6 (set (reg:DI 71)
        (const_int 0 [0x0])) 124 {*pa.md:4569} (nil)
    (nil))

(jump_insn 13 12 14 3 pr31944.c:6 (set (pc)
        (if_then_else (ne (reg/v/f:DI 69 [ res ])
                (reg:DI 71))
            (label_ref:DI 32)
            (pc))) 48 {*pa.md:1824} (nil)
    (expr_list:REG_BR_PROB (const_int 8500 [0x2134])
        (nil)))

(note 14 13 15 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 15 14 18 4 pr31944.c:6 (asm_input/v ("nop") ("pr31944.c") 6) -1 (nil)
    (nil))

(code_label 18 15 19 5 2 "" [1 uses])

(note 19 18 20 5 [bb 5] NOTE_INSN_BASIC_BLOCK)

(insn 20 19 21 5 pr31944.c:8 (set (reg:DI 72)
        (const_int 0 [0x0])) 124 {*pa.md:4569} (nil)
    (nil))

(jump_insn 21 20 22 5 pr31944.c:8 (set (pc)
        (if_then_else (ne (reg:DI 66 [ D.1605 ])
                (const_int 0 [0x0]))
            (label_ref:DI 32)
            (pc))) 48 {*pa.md:1824} (nil)
    (expr_list:REG_BR_PROB (const_int 4600 [0x11f8])
        (nil)))

(note 22 21 23 6 [bb 6] NOTE_INSN_BASIC_BLOCK)

(insn 23 22 24 6 pr31944.c:9 (set (reg:DI 73)
        (const_int 0 [0x0])) 124 {*pa.md:4569} (nil)
    (nil))

(jump_insn 24 23 25 6 pr31944.c:9 (set (pc)
        (if_then_else (ne (reg/v/f:DI 69 [ res ])
                (const_int 0 [0x0]))
            (label_ref:DI 32)
            (pc))) 48 {*pa.md:1824} (nil)
    (expr_list:REG_BR_PROB (const_int 8284 [0x205c])
        (nil)))

(note 25 24 26 7 [bb 7] NOTE_INSN_BASIC_BLOCK)

(insn 26 25 32 7 pr31944.c:10 (asm_operands/v ("nop") ("") 0 [
            (const_int 0 [0x0])
        ]
         [
            (asm_input:SI ("i") ("") 0)
        ] ("pr31944.c") 10) -1 (nil)
    (nil))

(code_label 32 26 35 8 4 "" [3 uses])

(note 35 32 0 8 [bb 8] NOTE_INSN_BASIC_BLOCK)

This problem is present in HEAD as well as 4.1.  Probably, 4.2 is affected as
well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

------- Comment #5 from danglin at gcc dot gnu dot org  2007-05-20 19:02 -------
In order to prevent flush_hash_table from looping forever, the call to
invalidate (p->exp, VOIDmode) has to remove the element p.  However, this
doesn't happen.  It only removes the entry if lookup_for_remove finds the
pseudo:

            /* Because a register can be referenced in more than one mode,
               we might have to remove more than one table entry.  */
            struct table_elt *elt;

            while ((elt = lookup_for_remove (x, hash, GET_MODE (x))))
              remove_from_table (elt, hash);

For some reason, reg:DI 66 isn't found:

(gdb) p lookup_for_remove (0x800003fffec89d00, 29, DImode)
$20 = (struct table_elt *) 0x0

I'm thinking that flush_hash_table should check p after calling invalidate
and call remove_from_table if it's nonzero.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

------- Comment #6 from danglin at gcc dot gnu dot org  2007-05-20 21:30 -------
This problem isn't present in 3.4.6.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-12-05 20:33:09
               date|                            |
            Summary|Endless loop while building |[4.1/4.2/4.3 Regression]
                   |a 64-bit 2.6.20 kernel      |Endless loop while building
                   |                            |a 64-bit 2.6.20 kernel


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2007-12-05 21:51 -------
Let's ask the Steven-o-racle ;)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #8 from steven at gcc dot gnu dot org  2007-12-05 22:29 -------
What does the full cse1 dump look like at that point (don't forget to call
fflush(dump_file) from gdb ;-)  Is this reproducible with a cross-compiler?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 23:17 -------
Subject: Re:  [4.1/4.2/4.3 Regression] Endless
        loop while building a 64-bit 2.6.20 kernel

> What does the full cse1 dump look like at that point (don't forget to call
> fflush(dump_file) from gdb ;-)  Is this reproducible with a cross-compiler?

gdb has trouble doing fflush(dump_file) on hppa64-hp-hpux11.11 ;-(

The problem seems to have gone away on the trunk.

I've attached pr31944.c.111r.jump and pr31944.c.112r.cse1.  The cse1
file has two dumps in it.  The second was taken at the time of the
hang.  These are using the stage1 compiler for hppa64-hp-hpux11.11,
version 4.2.3, revision 130785.

Dave


------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 23:17 -------
Created an attachment (id=14770)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14770&action=view)


------- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 23:17 -------
Created an attachment (id=14771)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14771&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

------- Comment #14 from danglin at gcc dot gnu dot org  2008-01-01 02:09 -------
This appears to have been fixed by the following change on the trunk:

2007-09-04  Jan Hubicka  <jh@suse.cz>

        * invoke.texi (-finline-small-functions): Document.
        * ipa-inline.c (cgraph_default_inline_p): Do not use DECL_INLINE
        when deciding what is inlinable.
        (cgraph_decide_recursive_inlining): Handle flag_inline_functions.
        (cgraph_decide_inlining_of_small_function): Handle new flags.
        (cgraph_decide_inlining_incrementally): Likewise.
        * opts.c (decode_options): Enable flag_inline_small_functions at -O2
        * common.opt (finline-small-functions): New.
        * Makefile.in (build/gengtype.o-warn): Work around PR29478


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[rguenther at suse dot de]

------- Comment #15 from rguenther at suse dot de  2008-01-01 16:59 -------
Subject: Re:  [4.1/4.2 Regression] Endless loop
 while building a 64-bit 2.6.20 kernel

On Tue, 1 Jan 2008, danglin at gcc dot gnu dot org wrote:

> This appears to have been fixed by the following change on the trunk:
> 
> 2007-09-04  Jan Hubicka  <jh@suse.cz>
> 
>         * invoke.texi (-finline-small-functions): Document.
>         * ipa-inline.c (cgraph_default_inline_p): Do not use DECL_INLINE
>         when deciding what is inlinable.
>         (cgraph_decide_recursive_inlining): Handle flag_inline_functions.
>         (cgraph_decide_inlining_of_small_function): Handle new flags.
>         (cgraph_decide_inlining_incrementally): Likewise.
>         * opts.c (decode_options): Enable flag_inline_small_functions at -O2
>         * common.opt (finline-small-functions): New.
>         * Makefile.in (build/gengtype.o-warn): Work around PR29478

So, can you verify if the problem persists if you build with
-fno-inline-small-functions?

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

------- Comment #16 from danglin at gcc dot gnu dot org  2008-01-01 21:26 -------
It does.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2 Regression] Endless|[4.1/4.2/4.3 Regression]
                   |loop while building a 64-bit|Endless loop while building
                   |2.6.20 kernel               |a 64-bit 2.6.20 kernel


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #17 from steven at gcc dot gnu dot org  2008-01-08 16:14 -------
Does anyone know how to reproduce this with a cross-compiler?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2008-01-08 16:29 -------
The testcase reproduces for me on a x86_64 -> hppa64-linux cross on trunk
with -O2 -fno-inline-small-functions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2008-01-09 15:36 -------
(reg:DI 66 [ type.0+-4 ]) is entered twice in the table.  During flushing we
hit:

Breakpoint 5, flush_hash_table ()
    at /space/rguenther/src/svn/trunk/gcc/cse.c:1634
1634            if (REG_P (p->exp))
(reg:DI 66 [ type.0+-4 ])
$14 = 1
$15 = (struct table_elt *) 0x1159440

...

Breakpoint 5, flush_hash_table ()
    at /space/rguenther/src/svn/trunk/gcc/cse.c:1634
1634            if (REG_P (p->exp))
(reg:DI 66 [ type.0+-4 ])
$32 = 5
$33 = (struct table_elt *) 0x11594a0
(gdb) print *p
$34 = {exp = 0x2ac6c01389a0, canon_exp = 0x0, next_same_hash = 0x0, 
  prev_same_hash = 0x0, next_same_value = 0x0, prev_same_value = 0x0, 
  first_same_value = 0x11594a0, related_value = 0x0, cost = 0, regcost = 1, 
  mode = SImode, in_memory = 0 '\0', is_const = 0 '\0', flag = -1 '�'}

and the hash of this reg is 29, not 5.

But for the first entry we come along the hash is 1 and matches.  So
I suppose we have twice the same pseudo in the table, but as we only
have one QTY per pseudo, the hash gets messed up.

Indeed, the time we try to remove the second entry the QTY is actually
invalid:

$74 = {timestamp = 1, reg_qty = -67, reg_tick = 3, reg_in_table = -1, 
  subreg_ticked = 4294967295}


Reduced testcase:

int type;
void stuck(int res)
{
  if (type == 1) {
    if (res == 0) asm volatile("nop");
  }
  else if (type == 0) {
    if (res == 0) asm volatile("nop" : : "i" (0));
  }
}

fails with -O2 on x86_64 -> hppa64-linux cross.

Steven - do you have an idea where to look further?  Thx.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #20 from steven at gcc dot gnu dot org  2008-01-09 19:09 -------
I still haven't been able to reproduce it with a cross and with the original
test case.  I'll try the reduced test case.  Wish me luck.  ;)


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-12-05 20:33:09         |2008-01-09 19:09:59
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #21 from steven at gcc dot gnu dot org  2008-01-09 22:46 -------
at cse.c:5418:
        elt = insert (dest, sets[i].src_elt,
                      sets[i].dest_hash, GET_MODE (dest));

dest = (reg:DI 66 [ type.0+-4 ])
sets[i].src_elt->exp = (sign_extend:DI (reg:SI 72 [ type ]))
sets[i].dest_hash = 5

and REG_QTY(66) == 5 so everything is OK up to this point.

Later on, REG_QTY(66) is changed.  This means that the original hash of 5 also
changes (the HASH of a reg is its QTY number plus a constant).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[janis at gcc dot gnu dot org]

------- Comment #22 from janis at gcc dot gnu dot org  2008-01-10 21:24 -------
Steven asked for a regression hunt, but will not be pleased by the results.  A
hunt using a hppa64-linux cross cc1 on powerpc-linux identified

    http://gcc.gnu.org/viewcvs?view=rev&rev=81764
    r81764 | dnovillo | 2004-05-13 06:41:07 +0000 (Thu, 13 May 2004)

which is the merge of tree-ssa-20020619-branch into mainline.  If it would be
helpful I could do a hunt on that branch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #23 from steven at gcc dot gnu dot org  2008-01-10 22:18 -------
Created an attachment (id=14916)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14916&action=view)
new test case that fails before the tree-ssa merge

I made a new test case out of the .final_cleanup dump, and Janis confirmed it
hangs even before the tree-ssa merge.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[janis at gcc dot gnu dot org]

------- Comment #24 from janis at gcc dot gnu dot org  2008-01-10 23:17 -------
A regression test using the test added in comment #23 identified:

    http://gcc.gnu.org/viewcvs?view=rev&rev=74332

    r74332 | sayle | 2003-12-05 14:06:46 +0000 (Fri, 05 Dec 2003)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #25 from steven at gcc dot gnu dot org  2008-01-10 23:44 -------
So this has been failing since at least GCC 3.4.  And I see nothing in the
identified patch that is related to how CSE handles its values, so I suspect
this bug exists in older compilers as well (just needs another test case,
maybe).

And I still have no idea what is really going wrong here...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #26 from steven at gcc dot gnu dot org  2008-01-10 23:58 -------
Mark, wrt. the release, I recommend this PR shouldn't be a blocker.  The
problem is old and is currently latent on the trunk, where it is only exposed
with non-default options (-fno-inline-small-functions).

Obviously, the problem is that the hash of reg 66 is changed after a hash table
element is created for it in the bucket for the original hash.  I have no idea
yet whether this is expected, or if not, what is going wrong.

Messing with CSE at this stage may be more dangerous than accepting the status
quo.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[ebotcazou at gcc dot gnu dot org]

------- Comment #27 from ebotcazou at gcc dot gnu dot org  2008-01-11 18:09 -------
> Obviously, the problem is that the hash of reg 66 is changed after a hash
> table element is created for it in the bucket for the original hash.  I have
> no idea yet whether this is expected, or if not, what is going wrong.

More precisely the QTY is changed after the reg has been entered with a hash.
This is expected, but the reg must be removed from the table.  The problem
here is that the reg is a pseudo and has been entered twice, for SImode and
DImode, but is only removed once.  Tentative fix to be attached.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[ebotcazou at gcc dot gnu dot org]

------- Comment #28 from ebotcazou at gcc dot gnu dot org  2008-01-11 18:09 -------
Created an attachment (id=14927)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14927&action=view)
Lightly tested fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca  2008-01-11 21:29 -------
Subject: Re:  [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit
2.6.20 kernel

Eric,

> More precisely the QTY is changed after the reg has been entered with a hash.
> This is expected, but the reg must be removed from the table.  The problem
> here is that the reg is a pseudo and has been entered twice, for SImode and
> DImode, but is only removed once.  Tentative fix to be attached.

I believe that you have solved the problem.  I did a quick cross build
on hppa-unknown-linux-gnu with your change on the trunk and it fixed the
endless loop.  I'm now doing a regular bootstrap and check.

Thanks,
Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[steven at gcc dot gnu dot org]

------- Comment #30 from steven at gcc dot gnu dot org  2008-01-12 00:25 -------
After playing with dbgcounts to see what happens, I indeed found the same as
what Eric notes in comment #27.  The proposed fix makes perfect sense.

I won't be fixing this, I think Eric has already proposed the correct fix.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[ebotcazou at gcc dot gnu dot org]

------- Comment #31 from ebotcazou at gcc dot gnu dot org  2008-01-12 00:30 -------
> After playing with dbgcounts to see what happens, I indeed found the same as
> what Eric notes in comment #27.  The proposed fix makes perfect sense.

Thanks.  Assigning to self.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-01-09 19:09:59         |2008-01-12 00:30:41
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[ebotcazou at gcc dot gnu dot org]

------- Comment #32 from ebotcazou at gcc dot gnu dot org  2008-01-14 12:17 -------
Subject: Bug 31944

Author: ebotcazou
Date: Mon Jan 14 12:16:58 2008
New Revision: 131522

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131522
Log:
        PR rtl-optimization/31944
        * cse.c (remove_pseudo_from_table): New function.
        (merge_equiv_classes): Use above function to remove pseudo-registers.
        (invalidate): Likewise.


Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/20080114-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cse.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[ebotcazou at gcc dot gnu dot org]

------- Comment #34 from ebotcazou at gcc dot gnu dot org  2008-01-14 12:20 -------
Subject: Bug 31944

Author: ebotcazou
Date: Mon Jan 14 12:19:58 2008
New Revision: 131524

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131524
Log:
        PR rtl-optimization/31944
        * cse.c (remove_pseudo_from_table): New function.
        (merge_equiv_classes): Use above function to remove pseudo-registers.
        (invalidate): Likewise.


Added:
    branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20080114-1.c
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/cse.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[ebotcazou at gcc dot gnu dot org]

------- Comment #33 from ebotcazou at gcc dot gnu dot org  2008-01-14 12:19 -------
Subject: Bug 31944

Author: ebotcazou
Date: Mon Jan 14 12:18:30 2008
New Revision: 131523

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131523
Log:
2008-01-14  Eric Botcazou  <ebotcazou@adacore.com>

        PR rtl-optimization/31944
        * cse.c (remove_pseudo_from_table): New function.
        (merge_equiv_classes): Use above function to remove pseudo-registers.
        (invalidate): Likewise.


Added:
    branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/20080114-1.c
Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/cse.c
    branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[ebotcazou at gcc dot gnu dot org]

------- Comment #35 from ebotcazou at gcc dot gnu dot org  2008-01-14 12:22 -------
On all branches.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2008-
                   |                            |01/msg00605.html
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944