On Mon, Feb 12, 2018 at 09:34:30PM -0600, Peter Bergner wrote:
> PR84279 is a similar problem to PR83399, in that we generate an altivec
> load/store through an explicit call to the altivec_{l,st}vx_v4si_2op
> pattern and then due to spilling, we end up calling recog() and we match
> an earlier pattern, in this case vsx_movv4si_64bit.  That is ok, since
> this pattern can generate the lvx/stvx insns the altivec patterm can.
> However, due to a constraint bug, we end up using the wrong alternative.

> Now we _should_ match using the second to last alternative, but we end up
> matching the 8th alternative ("??Y" and "r").  The 8th alternative is used for
> storing a GPR, which we have, but the mem we're trying to store to does not
> have a valid address for a GPR store.  The "bug" is that the "Y" constraint
> code, which is implemented by  mem_operand_gpr() allows our altivec address
> when it should not.  The following patch which fixes the ICE adds code to
> mem_operand_gpr() which disallows such addresses.
> This patch passed bootstrap and retesting on powerpc64le-linux with
> no regressions.  Ok for mainline?

Okay, thanks!  Does this need backports?

> --- gcc/testsuite/g++.dg/pr84279.C    (nonexistent)
> +++ gcc/testsuite/g++.dg/pr84279.C    (working copy)
> @@ -0,0 +1,35 @@
> +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */

I don't think this needs lp64?


Reply via email to