[PATCH] Fix ICEs in simplify_immed_subreg on OImode/XImode subregs (PR target/63910)

Jakub Jelinek jakub@redhat.com
Wed Nov 19 00:53:00 GMT 2014


On Tue, Nov 18, 2014 at 03:30:56PM -0800, Mike Stump wrote:
> > Before wide-int got merged, the testcase worked, though the code didn't
> > bother checking anything, just created 0 or constm1_rtx for the two cases
> > that could happen and if something else appeared, could just return what
> > matched low TImode (or DImode for -m32).
> 
> tmp is sized for MAX_BITSIZE_MODE_ANY_INT, but, you remove the limiter for
> units that keeps u in bounds.  Doesn’t this access 32 bytes of OImode
> values in a 16 byte data structure?

No, I'm not touching tmp array at all in that case, only look at vp
individual bytes.  Either they are all 0, or all 0xff, or I return NULL.

> and GET_MODE_BITSIZE (outer_submode) is > MAX_BITSIZE_MODE_ANY_INT, right?
> 
> You can’t copy more bytes than the size of the destination has?

On the testcase we have
(subreg:OI (reg:V8SI 1234) 0)
and try to propagate
(const_vector:V8SI [8 x (const_int 0)])
into it.  All zeros even in OImode (or XImode) is still
(const_int 0), all ones even in those modes is (const_int -1),
which are the only constants I'm using for those ultra-wide modes,
anything else will return NULL (but not ICE).

	Jakub



More information about the Gcc-patches mailing list