Re: [PATCH] tail merge ICE

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, May 4, 2016 at 7:25 PM, Nathan Sidwell <nathan@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