Hi!
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?
Segher
