[Bug c/50380] New: cc1 hangs eating 100% CPU

[Bug c/50380] New: cc1 hangs eating 100% CPU

[antipov at mvista dot com]

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

             Bug #: 50380
           Summary: cc1 hangs eating 100% CPU
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: antipov@mvista.com


Created attachment 25259
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25259
Preprocessed source

When compiling an attached code with optimization levels -O2, -O3, -Os, cc1
hangs and eats 100% CPU, producing the following output:

$ [path]/cc1 -fpreprocessed drd_clientreq.i -O2
toBool toUChar toHChar toUShort toShort toUInt Ptr_to_ULong ULong_to_Ptr
sr_isError sr_Res sr_ResHI sr_Err sr_EQ VALGRIND_PRINTF
VALGRIND_PRINTF_BACKTRACE vgDrd_vc_lte vgPlain_is_plausible_ECU
vgDrd_sg_get_refcnt vgDrd_sg_bm vgDrd_IsValidDrdThreadId
vgDrd_thread_get_running_tid vgDrd_thread_get_conflict_set
vgDrd_running_thread_inside_pthread_create
vgDrd_running_thread_is_recording_loads
vgDrd_running_thread_is_recording_stores vgDrd_thread_set_stack_min
vgDrd_thread_address_on_stack vgDrd_thread_address_on_any_stack
vgDrd_thread_get_segment vgDrd_running_thread_get_segment isIRAtom LibVEX_Alloc
vgDrd_any_address_is_traced vgDrd_clientreq_init handle_client_request
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> <visibility> <early_local_cleanups> <whole-program>
<ipa-profile> <cp> <inline> <pure-const> <static-var>Assembling functions:
 handle_client_request

Backtrace obtained from attached gdb may looks like the following:

#0  get_cse_reg_info (regno=229) at ../../gcc-4.6.1/gcc/cse.c:848
#1  exp_equiv_p (for_gcse=0 '\000', validate=0, y=0x7ff759016ba0,
x=0x7ff758fe68c0) at ../../gcc-4.6.1/gcc/cse.c:2657
#2  exp_equiv_p (x=0x7ff758fe68c0, y=0x7ff759016ba0, validate=0, for_gcse=0
'\000') at ../../gcc-4.6.1/gcc/cse.c:2603
#3  0x0000000000950b21 in lookup (x=0x7ff758fe68c0, hash=<optimized out>,
mode=SImode) at ../../gcc-4.6.1/gcc/cse.c:1500
#4  0x000000000095171b in find_comparison_args (code=EQ, parg1=0x7fff0ea30d98,
parg2=0x7fff0ea30da0, pmode1=0x7fff0ea30da8, 
    pmode2=0x7fff0ea30dac) at ../../gcc-4.6.1/gcc/cse.c:3029
#5  0x000000000095210d in fold_rtx (x=0x7ff75901e288, insn=0x7ff7590186e0) at
../../gcc-4.6.1/gcc/cse.c:3399
#6  0x0000000000951aa0 in fold_rtx (x=0x7ff759016de0, insn=0x7ff7590186e0) at
../../gcc-4.6.1/gcc/cse.c:3279
#7  0x0000000000955279 in cse_insn (insn=0x7ff7590186e0) at
../../gcc-4.6.1/gcc/cse.c:4511
#8  0x000000000095868d in cse_extended_basic_block (ebb_data=read_sleb128:
Corrupted DWARF expression.
) at ../../gcc-4.6.1/gcc/cse.c:6362
#9  cse_main (f=<optimized out>, nregs=<optimized out>) at
../../gcc-4.6.1/gcc/cse.c:6539
#10 0x0000000000958cae in rest_of_handle_cse () at
../../gcc-4.6.1/gcc/cse.c:7392
#11 0x000000000066ec89 in execute_one_pass (pass=0xddd2e0) at
../../gcc-4.6.1/gcc/passes.c:1556
#12 0x000000000066ef35 in execute_pass_list (pass=0xddd2e0) at
../../gcc-4.6.1/gcc/passes.c:1611
#13 0x000000000066ef47 in execute_pass_list (pass=0xdd85e0) at
../../gcc-4.6.1/gcc/passes.c:1612
#14 0x000000000073f931 in tree_rest_of_compilation (fndecl=0x7ff75910d500) at
../../gcc-4.6.1/gcc/tree-optimize.c:422
#15 0x000000000086026f in cgraph_expand_function (node=0x7ff75910f160) at
../../gcc-4.6.1/gcc/cgraphunit.c:1576
#16 0x0000000000861eba in cgraph_expand_all_functions () at
../../gcc-4.6.1/gcc/cgraphunit.c:1635
#17 cgraph_optimize () at ../../gcc-4.6.1/gcc/cgraphunit.c:1899
#18 0x00000000008622ba in cgraph_finalize_compilation_unit () at
../../gcc-4.6.1/gcc/cgraphunit.c:1096
#19 0x0000000000482985 in c_write_global_declarations () at
../../gcc-4.6.1/gcc/c-decl.c:9871
#20 0x0000000000704af6 in compile_file () at ../../gcc-4.6.1/gcc/toplev.c:591
#21 do_compile () at ../../gcc-4.6.1/gcc/toplev.c:1900
#22 toplev_main (argc=4, argv=0x7fff0ea313e8) at
../../gcc-4.6.1/gcc/toplev.c:1963
#23 0x00000038dc42139d in __libc_start_main () from /lib64/libc.so.6
#24 0x00000000004723c5 in _start ()

The same code compiles fine with -O1 and -O0.

Compiler was configured with Sourcery CodeBench Lite 2011.03-93 for MIPS
GNU/Linux libraries
(https://sourcery.mentor.com/sgpp/lite/mips/portal/package9057/public/mips-linux-gnu/mips-2011.03-93-mips-linux-gnu.bin)
with the following options:

../gcc-4.6.1/configure --prefix=/tmp/tools --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=mips-linux-gnu --enable-threads
--disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--with-arch=mips32r2 --with-float=hard --enable-multilib --with-mips-plt
--with-build-sysroot=/opt/codesourcery/mips/mips-linux-gnu/libc
--with-sysroot=/opt/codesourcery/mips/mips-linux-gnu/libc --enable-languages=c
--enable-shared --disable-lto --disable-nls --disable-libgomp

[Bug c/50380] cc1 hangs eating 100% CPU

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> 2011-09-21 19:17:10 UTC ---
I can reproduce the cc1-goes-into-a-cpu-consuming loop issue with gcc
4.6-20110916, 4.5-20110915, 4.4.3, 4.3.4, 4.2.4, and 4.1.2, built as crosses to
mips-linux.  However 4.7-20110917 seems to work.  Various native i686-linux gcc
versions also work.  Starting a bisection..

[Bug c/50380] cc1 hangs eating 100% CPU

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2011-09-21 23:30:32 UTC ---
The test case got unbroken on trunk by r176563:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00830.html

[Bug c/50380] cc1 hangs eating 100% CPU

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson <mikpe at it dot uu.se> 2011-09-22 08:51:19 UTC ---
Created attachment 25335
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25335
reduced test case

Much reduced test case.  So far I've only been able to reproduce the looping
cc1 with crosses to mips-linux.

[Bug rtl-optimization/50380] cc1 hangs eating 100% CPU

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-26 10:46:06 UTC ---
*** Bug 50474 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/50380] cc1 hangs eating 100% CPU

[sandra at gcc dot gnu.org]

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

--- Comment #5 from sandra at gcc dot gnu.org 2011-12-19 20:29:27 UTC ---
Author: sandra
Date: Mon Dec 19 20:29:21 2011
New Revision: 182498

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182498
Log:
2011-12-19  Sandra Loosemore  <sandra@codesourcery.com>
        Tom de Vries <tom@codesourcery.com>

    PR rtl-opt/50380

    gcc/
    * cse.c (find_comparison_args): Detect fixed point and
    bail early.

    gcc/testsuite/
    * gcc.c-torture/compile/pr50380.c: New testcase.

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

[Bug rtl-optimization/50380] [4.6 only] cc1 hangs eating 100% CPU

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to work|                            |4.7.0
           Keywords|                            |compile-time-hog
         Resolution|                            |FIXED
            Summary|cc1 hangs eating 100% CPU   |[4.6 only] cc1 hangs eating
                   |                            |100% CPU
   Target Milestone|---                         |4.7.0
      Known to fail|                            |4.3.0, 4.4.0, 4.5.0, 4.6.0
           Severity|major                       |normal

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-04 00:08:06 UTC ---
Fixed.

[Bug rtl-optimization/50380] [4.6 only] cc1 hangs eating 100% CPU

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #7 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Marked for reference. Resolved as fixed @bugzilla.

[Bug rtl-optimization/50380] [4.6 only] cc1 hangs eating 100% CPU

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50380

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
gnewsense devs ran into this problem on gnewsense, building libvpx's
vp9_cx_iface for mipsel-linux-gnu.  It happens on both gnewsense 3 (gcc 4.4ish)
and the upcoming gnewsense 4 (gcc 4.6ish).

I tracked it down to this bug, but I noticed the fix in it is incomplete; there
was a subsequent fix that complemented this one, that wasn't needed for the
testcase at hand, but I thought I'd help anyone else who ran into this problem
by adding a note to the subsequent fix as well:

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