[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> (gdb) p debug_rtx (x.first)
> (const_int 128 [0x80])
> (gdb) p x.second
> $2 = QImode
> (gdb) p precision 
> $3 = 8
> 
> the CONST_INT is not properly sign-extended.  This is from
> 
> #6  0x0000000000d55381 in simplify_const_binary_operation (code=ASHIFT, 
>     mode=QImode, op0=0x7ffff68d3490, op1=0x7ffff69e8b00)
>     at /space/rguenther/src/svn/trunk2/gcc/simplify-rtx.c:4001
> ...
> 3997            case LSHIFTRT:
> 3998            case ASHIFTRT:
> 3999            case ASHIFT:
> 4000              {
> 4001                wide_int wop1 = pop1;
> 4002                if (SHIFT_COUNT_TRUNCATED)
> 4003                  wop1 = wi::umod_trunc (wop1, width);
> 
> but of course the shift amount need not be QImode as well.  128 is quite
> large,
> but well...
> 
> Fact is that we don't know the mode of op1 here.  From the fact that the
> const_int is not sign-extended we can conclude its mode is larger than
> QImode.
> And we will truncate it anyway (or return NULL_RTX) if it is too large, so
> it doesn't even matter.

I take your point, but at the same time, is it really worth supporting shifts
whose shift amount is wider than the shifted value?  ISTM that no .md pattern
would want such a thing, so in practice this would only ever happen with debug
exprs.  I think the safest fix would be to make use_narrower_mode{,_test}
narrow the shift amount if it is wider than the target mode.  Just tried that
locally and it seems to fix the test case.

> I think we can simply use
> 
>               wide_int wop1 = std::make_pair (op1, MAX_MODE_INT);
> 
> here (or SImode maybe).  Or have a "don't care" way to make a wide-int
> from a CONST_INT directly.

Certainly SImode would be dangerous, since there's nothing to stop the same bug
reappearing with DImode.  MAX_MODE_INT is a problem because it can be wider
than MAX_BITSIZE_MODE_ANY_INT on targets like x86_64 that explicitly override
the wide_int size.  And I'd be reluctant to relax the general CONST_INT
semantics for such an oddball case.

Thanks,
Richard