On Fri, 12 Feb 2016, Jakub Jelinek wrote: > On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote: > > > > I am testing the following patch which fixes PR69771 where the code > > doesn't match the comment before it. We get to expand a QImode << QImode > > shift but the shift amount was of type int and thus it was expanded > > as SImode constant. Then > > > > /* In case the insn wants input operands in modes different from > > those of the actual operands, convert the operands. It would > > seem that we don't need to convert CONST_INTs, but we do, so > > that they're properly zero-extended, sign-extended or truncated > > for their mode. */ > > > > has to apply as we need to re-extend the VOIDmode CONST_INT for > > QImode. But then mode1 is computed as 'mode' (QImode) which happens > > to match what is expected even though the constant isn't valid. > > > > The fix is IMHO to always call convert_modes for VOIDmode ops > > (if the target doesn't expect VOIDmode itself). > > > > Bootstrap and regtest running on x86_64-unknown-linux-gnu, ok for trunk? > > This looks like the PR69764 fix I've sent last night (and updated patch > this morning). > BTW, I wouldn't use a runtime test with clearly undefined behavior, > especially not if it tests what the outcome of that UB is.
Ah, indeed looks like a dup. Let's go with your version which had feedback from Bernd already. Might want to add my testcase (w/o the runtime outcome test). Richard. > > 2016-02-12 Richard Biener <rguent...@suse.de> > > > > PR rtl-optimization/69771 > > * optabs.c (expand_binop_directly): Properly zero-/sign-extend > > VOIDmode operands. > > > > * gcc.dg/torture/pr69771.c: New testcase. > > Jakub
