[RFC/RFT] PR/25890 and PR/25905

[Paolo Bonzini]

It turns out that the assertion checks I added in my last combine patch 
trigger on about every target but the ones I tested.  ;-)  These 
assertions tested for invalid zero_extract and sign_extract expressions, 
where the initial and/or final positions are out of the first operand's 
bounds.

Some of these failures (PR25890) are caused by combine trying to 
synthesize invalid shifts.  These could be easily fixed in combine itself.

Some other failures however are caused by bitfield operations.  Expand 
is more than happy to create QImode memory accesses independent of the 
width of the bitfield.  Fixing this is a mess because some machine 
descriptions, in turn, *expect* this to be true and use a 
(match_operand:QI 0 "memory_operand") in their extv/extzv patterns.  In 
other word, this would require the rework of the insv/extv/extzv 
patterns that was mentioned a while ago.  This is not appropriate for a 
build-breaking bug, during the slush, and while I have little time to 
devote to FSF GCC development.

For this reason I'm inclined to disable combine's transformations, and 
return a (clobber (const_int 0)), in presence of "invalid" extractions. 
The attached patch does exactly this.  I'm bootstrapping it overnight, 
but I'll post it right now so that people affected by the bug can also 
test it.

Ok for mainline if it passes?

Paolo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: my-combine-bugs-easy.patch
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20060123/d0bf55d4/attachment.ksh>