https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2014-09-08
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So it's independend of LTO.
Confirmed. We have
_28 = &MEM[(struct Array *)&fa + 256B].a[0] + _3;
*_28 = u_23;
which SCEV messes up because it ends up with
(instantiate_scev
(instantiate_below = 4)
(evolution_loop = 1)
(chrec = &MEM[(struct Array *)&fa + 256B].a[0])
(res = &MEM[(struct Array *)&fa + 256B].a[0]))
(instantiate_scev
(instantiate_below = 4)
(evolution_loop = 1)
(chrec = {(long unsigned int) first_6(D) * 4, +, 4}_1)
(res = {(long unsigned int) first_6(D) * 4, +, 4}_1))
(set_scalar_evolution
instantiated_below = 4
(scalar = _13)
(scalar_evolution = {&MEM[(struct Array *)&fa + 256B].a[(sizetype)
first_6(D)], +, 4}_1))
)
failed: evolution of base is not affine.
Not sure why it thinks that.
Btw, on trunk we now vectorize this just fine probably because of the fix
for PR63148 which avoids moving first_6 * 4 inside the array-ref and we
get
(scalar_evolution = {&MEM[(struct Array *)&fa + 256B].a[0] + (sizetype)
((long unsigned int) first_6(D) * 4), +, 4}_1))
)
success.
instead.
So - can you re-check please?
