https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #9 from kelvin at gcc dot gnu.org ---
The new tests proposed by as part of this PR represent illegal code and are
properly rejected by the compiler.
However, the compiler is not currently rejecting the following test program
even though the test depends on undefined behavior. This test is defined in
vec-extract.h, which is included by 14 expansions of vec-extract-v*.c.
/* Tests for vec_extract where the vector comes from memory (the compiler can
optimize this by doing a scalar load without having to load the whole
vector). */
RTYPE
get_pointer_n (vector TYPE *p, ssize_t n)
{
return (RTYPE) vec_extract (*p, n);
}
...
void
do_pointer (vector TYPE *p)
{
size_t i;
for (i = 0; i < sizeof (get_pointer_const) / sizeof (get_pointer_const[0]);
i\
++)
{
TRACE ("pointer", i);
check (get_pointer_n (p, i), (get_pointer_const[i]) (p));
}
}
This is the code from which the newly proposed tests were derived.
I am inclined to remove this code from the test suite under the principle that
optimizers should not change the legality of code. If the code is illegal
without optimization, it should still be illegal with optimization. In that
spirit, I would think we do not ever want to allow non-constant values as the
selector argument to vec_extract.
I haven't yet confirmed whether the compiler considers this "legal" only
because it fully unrolls the loop and in-lines get_pointer_n or if it is
considered legal because, given a pointer to a vector, the expansion uses a
different implementation technique than it would use in the case of direct move
for an in-register vector.
If we do consider it legal to use vec_extract with a variable selector on
in-memory vectors, then I would want to make sure the semantics is the same
with regards to modular truncation of the selector expression...
I couldn't resist glancing at the implementation of vec_extract in rs6000-c.c.
I haven't experimented but the following comment around line 6024 causes some
concern:
/* If the second argument is variable, we can optimize it if we are
generating 64-bit code on a machine with direct move. */
Am looking for advice on next steps here.
Am happy to simply close this problem report if that's the right thing to do.
