--- 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
--- 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 t
--- 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
--- 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 0x40c5a274 in get_cse_reg_info (regno=66)
at ../../gcc/gcc/cse.c:847
#1
--- 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
--- 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
