I tested trunk and an old 4.2.1 internal branch, and found the bug on
both, so anything in between would be affected too. It goes back at
least to this patch, which mostly fixed the bug:
2008-02-19 Christian Bruel christian.br...@st.com
Zdenek Dvorak o...@ucw.cz
*
I can confirm this fixes my test case. Had I known about
highest_pow2_factor() I might have come up with this myself ;-)
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c(revision 158148)
+++
I can confirm this fixes my test case. Had I known about
highest_pow2_factor() I might have come up with this myself ;-)
OK, I'll do some testing with it tomorrow. Which GCC versions are affected?
--
Eric Botcazou
OK, I'll do some testing with it tomorrow. Which GCC versions are affected?
I tested trunk and an old 4.2.1 internal branch, and found the bug on
both, so anything in between would be affected too. It goes back at
least to this patch, which mostly fixed the bug:
2008-02-19 Christian Bruel
As a workaround, I had may_be_unaligned_p() return true if toffset is
set, but there's likely times when that results in suboptimal code.
Wouldn't this be sufficient?
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c(revision 158148)
+++ tree-ssa-loop-ivopts.c(working copy)
@@ -1546,6 +1546,9 @@ may_be_unaligned_p (tree ref, tree step)
|| bitpos % BITS_PER_UNIT !=
In tree-ssa-loop-ivopts.c:may_be_unaligned_p(), we call
get_inner_reference to figure out bitpos, but we don't take into
account toffset - which may make the reference less aligned than we
expect. Is this supposed to be accounted for by STEP ? It doesn't
always work with nested arrays - STEP is
