This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 12 Feb 2016 11:32:03 +0100
- Subject: Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1602121119020 dot 31122 at t29 dot fhfr dot qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
> 2016-02-12 Richard Biener <rguenther@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