By the way, just to follow up on a conversation we had offline: I did a little poking, and found that the assembler objects if any of these out-of-range arguments to vspltb, etc., survive the compiler:
/tmp/cctyppYZ.s: Assembler messages: /tmp/cctyppYZ.s:25: Error: operand out of range (-1 is not between 0 and 3) So if the test had been written with dg-do assemble instead of dg-do compile, we would have found the issue long ago. Anyway, I was looking into adding error checking for this in the compiler, but now that seems redundant. Thanks, Bill On Mon, 2014-09-29 at 13:44 -0400, David Edelsohn wrote: > On Mon, Sep 29, 2014 at 1:27 PM, Bill Schmidt > <wschm...@linux.vnet.ibm.com> wrote: > > Hi, > > > > While working on another patch, I observed that the test case > > gcc.dg/vmx/ops.c contains numerous calls to vec_splat and friends for > > which the second argument (the element selector) is out of range. At > > best these calls are invalid; as it is, we generate insns that can cause > > trouble during optimization. (In the case I saw, simplify-rtx tried to > > reduce the splat of its input at compile time, but the out-of-range > > element selector caused it to report a bad insn and abort.) This patch > > removes all of the calls with out-of-range element selectors from the > > test case. > > > > Tested on powerpc64le-unknown-linux-gnu. Ok to commit? > > > > Thanks, > > Bill > > > > > > 2014-09-29 Bill Schmidt <wschm...@vnet.linux.ibm.com> > > > > * gcc.dg/vmx/ops.c: Remove calls to vec_splat, vec_vsplth, > > vec_vspltw, and vec_vspltb for which the second argument is out of > > range. > > Okay. > > Thanks, David >
