Bug 50380

Summary: [4.6 only] cc1 hangs eating 100% CPU
Product: gcc Reporter: Dmitry Antipov <antipov>
Component: rtl-optimizationAssignee: Not yet assigned to anyone <unassigned>
Severity: normal CC: aoliva, jackie.rosen, mikpelinux, steffen-schmidt
Priority: P3 Keywords: compile-time-hog
Version: 4.6.1   
Target Milestone: 4.7.0   
Host: Target: mips-linux
Build: Known to work: 4.7.0
Known to fail: 4.3.0, 4.4.0, 4.5.0, 4.6.0 Last reconfirmed:
Attachments: Preprocessed source
reduced test case

Description Dmitry Antipov 2011-09-13 09:05:35 UTC
Created attachment 25259 [details]
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:

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
Comment 1 Mikael Pettersson 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..
Comment 2 Mikael Pettersson 2011-09-21 23:30:32 UTC
The test case got unbroken on trunk by r176563:

Comment 3 Mikael Pettersson 2011-09-22 08:51:19 UTC
Created attachment 25335 [details]
reduced test case

Much reduced test case.  So far I've only been able to reproduce the looping cc1 with crosses to mips-linux.
Comment 4 Richard Biener 2011-09-26 10:46:06 UTC
*** Bug 50474 has been marked as a duplicate of this bug. ***
Comment 5 sandra 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
2011-12-19  Sandra Loosemore  <sandra@codesourcery.com>
	    Tom de Vries <tom@codesourcery.com>

	PR rtl-opt/50380

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

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

Comment 6 Andrew Pinski 2012-01-04 00:08:06 UTC
Comment 7 Jackie Rosen 2014-02-16 10:01:16 UTC Comment hidden (spam)
Comment 8 Alexandre Oliva 2015-02-04 05:21:20 UTC
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: