This can be related to pr41371, but I think it is not duplicate. This one ends in endless loop, as can be seen from -fdump-rtl-vartrack dumps - there are about 50 lines periodically repeating. I thought it's a dup of pr41371, but the compilation (of nonreduced testcase) didn't finish even after one week. Reduced testcase compilation finishes "in miliseconds" with -fno-var-tracking, but takes forever without it. It's not slowly eating memory, so it never crashes. Command line: gcc -O3 -g -fgcse-sm -ftracer testcase.c Tested revisions (x86_64): r156217 - fail r156038 - fail r155945 - fail (x86) r155920 - fail r155917 - fail r155902 - OK r155844 - OK (x86) r155833 - OK r155363 - OK r154886 - OK r153685 - OK 4.4 branch, r155365 - OK Output (manually terminated): $ time /mnt/svn/gcc-trunk/binary-155920-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 -v -O3 -g -fgcse-sm -ftracer testcase.c ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/mnt/svn/gcc-trunk/binary-155920-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /mnt/svn/gcc-trunk/binary-155920-lto/include /mnt/svn/gcc-trunk/binary-155920-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /mnt/svn/gcc-trunk/binary-155920-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list. baz bar foo Analyzing compilation unit Performing interprocedural optimizations <visibility> <*free_lang_data> <early_local_cleanups> <whole-program> <cp> <inline> <static-var> <pure-const>Assembling functions: foo^C real 76m32.295s user 74m33.830s sys 0m0.730s
Created attachment 19713 [details] reduced testcase Command line: gcc -O3 -g -fgcse-sm -ftracer pr42873.c -c
Since http://gcc.gnu.org/viewcvs?view=revision&revision=155917
Seems s is alternating between VALUE 1 and VALUE 11: dataflow difference found: old and new follow: name: s offset 0 (value/s/u:DI 1 @0x2ff4100/0x3009f40) name: s offset 0 (value/s/u:DI 11 @0x2ff4478/0x3013980) ... dataflow difference found: old and new follow: name: s offset 0 (value/s/u:DI 11 @0x2ff4478/0x3013980) name: s offset 0 (value/s/u:DI 1 @0x2ff4100/0x3009f40) Both VALUE 1 and 11 are created for (reg/v/f:DI 5 di [orig:177 s ] [177]) which is a fn parameter and hasn't been ever modified within the function, supposedly just 1 and 11 are created in different bbs.
When doing dataflow_set_merge where s variable is in VALUE 1 in one hash table and in VALUE 11 in the other hash table, apparently always the one that is first wins, as VALUE 11 has var->var_part[0].loc_chain->loc VALUE 1 and vice versa, so intersect_loc_chains just picks the first one.
Subject: Bug 42873 Author: jakub Date: Thu Mar 18 20:16:48 2010 New Revision: 157548 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157548 Log: PR debug/42873 * var-tracking.c (canonicalize_vars_star): New. (dataflow_post_merge_adjust): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
Fixed, thanks Alex.