[Bug target/28672] New: [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[Bug target/28672] New: [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

With revision 116045, gcc mainline went into infinite loop when compiling
libstdc++-v3/src/wlocale-inst.cc.


-- 
           Summary: [4.2 Regression]: Gcc went into infinite loop when
                    building libstdc++
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-10 02:08 -------
Testcase?
Do you ever follow directions?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
           Keywords|                            |wrong-code
   Target Milestone|---                         |4.2.0


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

------- Comment #2 from hjl at lucon dot org  2006-08-10 06:16 -------
Created an attachment (id=12050)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12050&action=view)
A tescase

This is the best I can get so far. Gcc hangs with -O2 -g.


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

------- Comment #3 from hjl at lucon dot org  2006-08-10 06:22 -------
This patch

http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00238.html

causes the gcc to hang. Gdb backtrace looks like

(gdb) bt
#0  htab_find_slot_with_hash (htab=0x60000000002cce30,
    element=0x2000000005417b20, hash=30308, insert=NO_INSERT)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/libiberty/hashtab.c:635
#1  0x40000000008f8310 in delete_variable_part (set=0x600000000053c630,
    loc=0x2000000005779b80, decl=0x2000000005417b20, offset=0)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:2232
#2  0x40000000008f8b80 in var_regno_delete (set=0x600000000053c630,
    regno=<value optimized out>)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:916
#3  0x40000000008fb1c0 in vt_find_locations ()
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:1729
#4  0x40000000008fc210 in variable_tracking_main ()
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:2951
#5  0x4000000000788b80 in ia64_reorg ()
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/config/ia64/ia64.c:8549
#6  0x400000000090e330 in rest_of_handle_machine_reorg ()
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/reorg.c:3816
#7  0x400000000071b830 in execute_one_pass (pass=0x6000000000008d88)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:864
#8  0x400000000071bbb0 in execute_pass_list (pass=0x6000000000008d88)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:911
#9  0x400000000071bc00 in execute_pass_list (pass=0x60000000000076c0)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:912
---Type <return> to continue, or q <return> to quit---
#10 0x400000000071bc00 in execute_pass_list (pass=0x6000000000007678)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:912
#11 0x400000000022e960 in tree_rest_of_compilation (fndecl=0x2000000004e7ddc0)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/tree-optimize.c:418
#12 0x40000000001342a0 in expand_body (fn=0x2000000004e7ddc0)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cp/semantics.c:3072
#13 0x4000000000794a30 in cgraph_expand_function (node=0x2000000004f23e90)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cgraphunit.c:1194
#14 0x40000000007967f0 in cgraph_optimize ()
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cgraphunit.c:1259
#15 0x40000000000ac070 in cp_finish_file ()
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cp/decl2.c:3341
#16 0x40000000000038a0 in finish_file ()
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cp/cp-lang.c:144
#17 0x40000000001e8e00 in c_common_parse_file (
    set_yydebug=<value optimized out>)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/c-opts.c:1165
#18 0x40000000006c6240 in toplev_main (argc=<value optimized out>,
    argv=<value optimized out>)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/toplev.c:999
#19 0x4000000000202c40 in main (argc=17, argv=0x60000fffffffb5a8)
    at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/main.c:35
(gdb)


-- 

hjl at lucon dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu dot
                   |                            |org
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-08-10 06:22:20
               date|                            |


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[tbm at gcc dot gnu dot org]

------- Comment #4 from tbm at gcc dot gnu dot org  2006-08-10 11:53 -------
*** Bug 28676 has been marked as a duplicate of this bug. ***


-- 

tbm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schwab at suse dot de


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[tbm at gcc dot gnu dot org]

-- 

tbm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

------- Comment #5 from hjl at lucon dot org  2006-08-10 15:21 -------
I can reproduce the hang with a cross compiler from Linux/i686 to Linux/ia64.
It looks like the compiler is miscompiled.


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

------- Comment #6 from hjl at lucon dot org  2006-08-11 18:40 -------
The loop in vt_find_locations starts with

Basic block 22:
IN:
Stack adjustment: 80
Reg 8: __ret+0
Reg 15: this+0 this+0
Reg 32: __ret+0
Reg 33: __ret+0
Reg 35: __c+0
Reg 112: this+0
Reg 113: __ret+0
Reg 114: __ret+0
Reg 115: __ret+0
Reg 117: __io+0
Reg 118: __err+0
Reg 119: __xtrc+0
Variables:
  name: __xtrc
    offset 0
      (reg:DI 119 r39 [ __xtrc ])
  name: __ret
    offset 0
      (reg/v:SI 113 r33 [orig:342 __ret.739 ] [342])
      (reg/v:SI 8 r8 [orig:363 __ret ] [363])
  name: __ret
    offset 0
      (reg/v:SI 33 r41 [orig:355 __ret ] [355])
  name: __ret
    offset 0
      (reg/v:SI 115 r35 [orig:339 __ret.742 ] [339])
  name: __c
    offset 0
      (reg/v:SI 35 r43 [orig:380 __c ] [380])
  name: this
    offset 0
      (reg:DI 15 r15 [orig:371 this ] [371])
  name: __ret
    offset 0
      (reg/v:SI 114 r34 [orig:341 __ret.740 ] [341])
  name: __ret
    offset 0
      (reg/v:SI 32 r40 [orig:343 __ret.738 ] [343])
  name: this
    offset 0
      (reg:DI 112 r32 [ this ])
  name: this
    offset 0
      (reg:DI 15 r15 [orig:361 this ] [361])
  name: __io
    offset 0
      (reg:DI 117 r37 [ __io ])
  name: __err
    offset 0
      (reg:DI 118 r38 [ __err ])

After recomputing the input:

Basic block 22:
IN:
Stack adjustment: 80
Reg 15: this+0 this+0
Reg 32: __ret+0
Reg 33: __ret+0
Reg 35: __c+0
Reg 112: this+0
Reg 113: __ret+0
Reg 114: __ret+0
Reg 115: __ret+0
Reg 117: __io+0
Reg 118: __err+0
Reg 119: __xtrc+0
Variables:
  name: __xtrc
    offset 0
      (reg:DI 119 r39 [ __xtrc ])
  name: __ret
    offset 0
      (reg/v:SI 113 r33 [orig:342 __ret.739 ] [342])
  name: __ret
    offset 0
      (reg/v:SI 33 r41 [orig:355 __ret ] [355])
  name: __ret
    offset 0
      (reg/v:SI 115 r35 [orig:339 __ret.742 ] [339])
  name: __c
    offset 0
      (reg/v:SI 35 r43 [orig:380 __c ] [380])
  name: this
    offset 0
      (reg:DI 15 r15 [orig:371 this ] [371])
  name: __ret
    offset 0
      (reg/v:SI 114 r34 [orig:341 __ret.740 ] [341])
  name: __ret
    offset 0
      (reg/v:SI 32 r40 [orig:343 __ret.738 ] [343])
  name: this
    offset 0
      (reg:DI 112 r32 [ this ])
  name: this
    offset 0
      (reg:DI 15 r15 [orig:361 this ] [361])
  name: __io
    offset 0
      (reg:DI 117 r37 [ __io ])
  name: __err
    offset 0
      (reg:DI 118 r38 [ __err ])

(reg/v:SI 8 r8 [orig:363 __ret ] [363]) is gone. But it is put back later. It
goes into a infinite loop. The instruction in question is

(insn 1138 1137 1233 73 x.cc:23406 (cond_exec (eq (reg:BI 262 p6 [489])
            (const_int 0 [0x0]))
        (set (reg/v:SI 113 r33 [orig:342 __ret.739 ] [342])
            (reg/v:SI 8 r8 [orig:363 __ret ] [363]))) 781
{sync_lock_releasedi+4} (nil)
    (expr_list:REG_DEAD (reg/v:SI 8 r8 [orig:363 __ret ] [363])
        (expr_list:REG_DEAD (reg:BI 262 p6 [489])
            (nil))))

Is this really a MO_COPY since r8 is dead after it. I tried

--- var-tracking.c.debug        2006-08-09 19:53:01.000000000 -0700
+++ var-tracking.c      2006-08-11 11:22:03.000000000 -0700
@@ -1671,6 +1671,9 @@ add_stores (rtx loc, rtx expr, void *ins
        mo->type = MO_CLOBBER;
       else if (GET_CODE (expr) == SET
               && SET_DEST (expr) == loc
+              && (! REG_P (SET_SRC (expr))
+                  || ! find_regno_note ((rtx) insn, REG_DEAD,
+                                        REGNO (SET_SRC (expr))))
               && same_variable_part_p (SET_SRC (expr),
                                        REG_EXPR (loc),
                                        REG_OFFSET (loc)))

It seems to work for libstdc++-v3/src/wlocale-inst.cc.


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[aoliva at gcc dot gnu dot org]

------- Comment #7 from aoliva at gcc dot gnu dot org  2006-08-15 07:23 -------
I believe it should be a MO_COPY, yes, in spite of the REG_DEAD note.  That's
because, even though GCC no longer cares about the register content, the value
is actually still there until something else writes to it.

That said, it's not like the patch could hurt, methinks.  I'll see if I can
find a deeper cause for the problem using the testcase.  Thanks!


-- 

aoliva at gcc dot gnu dot org changed:

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


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[aoliva at gcc dot gnu dot org]

------- Comment #8 from aoliva at gcc dot gnu dot org  2006-08-15 10:12 -------
Created an attachment (id=12076)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12076&action=view)
Patch that appears to fix the bug

The problem was that we were killing unrelated live variables while clobbering
the contents of a specific variable part.  This patch adjusts this and adds
some improvements to dataflow set dumping.  I'm bootstrapping it on
amd64-linux-gnu and, if it proves to be good, I'll post it to the gcc-patches.


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[aoliva at gcc dot gnu dot org]

------- Comment #9 from aoliva at gcc dot gnu dot org  2006-08-15 10:22 -------
Err, there's at least one bug in the patch that cause an early bootstrap crash.
 Replacing both occurrences of (loc) with (node->loc), which was what I had
intended, fixes it.


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[schwab at suse dot de]

------- Comment #10 from schwab at suse dot de  2006-08-15 15:22 -------
The first hunk generates a warning since tree != void *.


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

------- Comment #11 from hjl at lucon dot org  2006-08-17 15:53 -------
This patch

http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00521.html

works for me on ia64:

http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg00722.html


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[sje at cup dot hp dot com]

------- Comment #12 from sje at cup dot hp dot com  2006-08-22 16:46 -------
The patch mentioned in comment #11 also works for me.  Note that I had to only
use the patch that fixed the bug, the sencond patch / rest of the patch that is
for improved debuggability caused warnings during bootstraps and would not
work.  The exact patch that I tested was:

http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00661.html


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at gcc dot gnu dot org]

------- Comment #13 from hjl at gcc dot gnu dot org  2006-09-11 21:30 -------
Subject: Bug 28672

Author: hjl
Date: Mon Sep 11 21:30:07 2006
New Revision: 116859

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116859
Log:
2006-09-11  Alexandre Oliva  <aoliva@redhat.com>

        PR target/28672
        * var-tracking.c (dump_dataflow_set): Start dumping at
        register zero.
        (clobber_variable_part): Kill only the variable part in
        registers holding it, leaving other variables alone.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-09-11 23:11 -------
Fixed.


-- 


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

------- Comment #15 from hjl at lucon dot org  2006-09-12 00:35 -------
Fixed:

http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00586.html


-- 

hjl at lucon dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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