On Wed, May 4, 2016 at 7:25 PM, Nathan Sidwell <nat...@codesourcery.com> wrote: > This patch fixes an ICE Thomas observed in tree-ssa-tail-merge.c: > > On 05/03/16 06:34, Thomas Schwinge wrote: > >> I'm also seeing the following regression for C and C++, >> libgomp.oacc-c-c++-common/loop-auto-1.c with -O2: >> >> source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-auto-1.c: >> In function 'vector_1._omp_fn.0': >> >> source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-auto-1.c:104:9: >> internal compiler error: Segmentation fault >> #pragma acc parallel num_workers (32) vector_length(32) >> copy(ary[0:size]) firstprivate (size) >> ^ >> >> #4 0x0000000000f73d46 in internal_error >> (gmsgid=gmsgid@entry=0x105be63 "%s") >> at [...]/source-gcc/gcc/diagnostic.c:1270 >> #5 0x00000000009fccb0 in crash_signal (signo=<optimized out>) >> at [...]/source-gcc/gcc/toplev.c:333 >> #6 <signal handler called> >> #7 0x0000000000beaf2e in same_succ_flush_bb (bb=<optimized out>, >> bb=<optimized out>) >> at [...]/source-gcc/gcc/hash-table.h:919 >> #8 0x0000000000bec499 in same_succ_flush_bbs (bbs=<optimized out>) >> at [...]/source-gcc/gcc/tree-ssa-tail-merge.c:823 > > > What's happening is we're trying to delete an object from a hash table, and > asserting that we did indeed find the object. The hash's equality function > compares gimple sequences and ends up calling gimple_call_same_target_p. > That returns false if the call is IFN_UNIQUE, and so the deletion fails to > find anything. IFN_UNIQUE function calls should not compare equal, but they > should compare eq (in the lispy sense). > > The local fix is to augment the hash compare function with a check for > pointer equality. That way deleting items from the table works and > comparing different sequences functions as before. > > The more general fix is to augment gimple_call_same_target_p so that unique > fns are eq but not equal. A cursory look at the other users of that > function did not indicate this currently causes a problem, but IMHO it is > odd for a value to not compare the same as itself -- though IEEE NaNs do > that :) > > I placed the pointer equality comparison in gimple_call_same_target_p after > the check for unique_fn_p, as I suspect that it is the rare case for that to > be called with the same gimple call object for both parameters. Although > pointer equality would be applicable to all cases, in most instances it's > going to be false. > > Of course, the gimple_call_same_target_p change fixes the problem on its > own, but the local change to same_succ::equal seems beneficial on its own > merits. > > ok?
Ok. Richard. > nathan > -- > Nathan Sidwell