On 22.02.2010 22:41, Janis Johnson wrote:
On Mon, 2010-02-22 at 13:11 -0800, Andrew Pinski wrote:
On Mon, Feb 22, 2010 at 1:06 PM, Janis Johnson<janis...@us.ibm.com> wrote:
If you can reproduce the problem with a small, self-contained test then
please file a bug report. It might be possible to issue a warning or
to detect that the loop should not be vectorized. If not, maybe the
compiler should disable vectorization for -fno-strict-aliasing.
It is not an aliasing issue but an alignment issue. Anyways this is
most likely the same as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009 .
Yes, that's the problem I had in mind but I was thinking about an
explicit cast to a pointer to more-aligned data in the function that has
the vector loop. There's no way to warn about the undefined behavior
when the cast is in a different source file.
It's interesting that two reports of failure due to this same undefined
behavior come so close together.
I wonder if it might be feasible to have a flag which inserts code to
check for alignment assumptions and complain if they're not met, to
check for things like this.
(And then possibly to insert similar code for other assumptions gcc
makes that are fairly easy to check at runtime.)
Not alternate code paths, just something like an assert that the code
behaves like gcc feels justified in assuming it should, and the
programmer didn't do anything stupid - as long as it's fairly simple to
check, such as the actual alignment of a pointer or perhaps the actual
limit of a loop or some such; and as long as the assumption actually
influences code generation decisions.
