On Tue, Feb 16, 2016 at 10:05:55AM +0100, Richard Biener wrote:
> On Tue, 16 Feb 2016, Jakub Jelinek wrote:
>
> > On Mon, Feb 15, 2016 at 08:43:22PM +0100, Richard Biener wrote:
> > > On February 15, 2016 7:15:35 PM GMT+01:00, Jakub Jelinek
> > > <ja...@redhat.com> wrote:
> > > >On Mon, Feb 15, 2016 at 06:58:45PM +0100, Richard Biener wrote:
> > > >> We could also force_reg those at expansion or apply
> > > >SHIFT_COUNT_TRUNCATED to those invalid constants there.
> > > >
> > > >Sure, but for force_reg we'd still need the gen_int_mode anyway.
> > > >As for SHIFT_COUNT_TRUNCATED, it should have been applied already from
> > > >the
> > > >caller - expand_shift_1.
> > >
> > > But then no out of bound values should remain.
> > > Until we get 256bit ints where your workaround wouldn't work either?
> >
> > Of course it would work, because in that case mode would be OImode, not
> > QImode, and thus the code would ensure the shift count is valid OImode
> > constant.
>
> Ah, yes - here we're still using op0 mode. For OImode wouldn't we
> get a CONST_DOUBLE or CONST_WIDE_INT though?
I think the C/C++ FEs use unsigned int for the type of the shift count in
any case, so op1 will still be CONST_INT.
> > Here is a variant of that patch with force_reg, seems to work on
> > aarch64 and x86_64.
>
> Works for me.
Ok, will bootstrap/regtest it today and commit if it passes testing.
Jakub
