[lno] internal compiler error: in record_dependences_for_modify_expr, at tree-scalar-evolution.c:3236

[Richard Guenther]

Btw. - all the use of switch (TREE_CODE_LENGTH (TREE_CODE (x))) in 
tree-scalar-evolution.c looks fragile, no?  Shouldn't this switch for 
the TREE_CODE(x) instead to avoid surprises?  At least a comment should 
describe why this "optimization" is legal.

For the ICE below, s/abort()/return/ works for me, but that doesn't look 
less fragile either ;)

Richard.

Richard Guenther wrote:
> Richard Guenther wrote:
> 
>> Hi!
>>
>> With todays CVS I get the following ICE with the tramp3d-v2 testcase at
>> http://www.tat.physik.uni-tuebingen.de/~rguenth/gcc/tramp3d-v2.cpp.gz
>>
>> ~/ix86/gccssa-lno/bin/g++ -o tramp3d-v2 tramp3d-v2.cpp -O2 -msse2 
>> -ftree-vectorize
>> tramp3d-v2.cpp: In member function `void RelationList::setDirty() const':
>> tramp3d-v2.cpp:47400: internal compiler error: in 
>> record_dependences_for_modify_expr, at tree-scalar-evolution.c:3236
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>>
>> trying to debug this with gdb, my gdb version (5.3) segfaults at 
>> setting the breakpoint to the above location.  So you have to dig for 
>> your own - but maybe TREE_CODE_LENGTH (TREE_CODE (rhs)) is ... 3? 
>> (dunno, function call, I assume).
> 
> 
> Grepping through tree.def there are tree codes with lengths 3 and 4 
> which encountered, whould ICE here.  Amongst them vtable-ref which seems 
> to be a likely candidate (the elem(i)->setDirty() call is polymorphic).
> 
> Richard.
> 
>>
>> The code failing looks actually like
>>
>> struct RelationList {
>>   void setDirty() const
>>     {
>>       for (int i = 0; i < list_m->size(); ++i)
>>         list_m->elem(i)->setDirty();
>>     }
>> private:
>>   RefCountedPtr<RelationListData> list_m;
>> };
>>
>> where ->elem() returns an element of std::vector<RelationListItem *>.
>>
>> Richard.
>>
>