https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Keywords| |missed-optimization Last reconfirmed| |2015-08-25 CC| |rguenth at gcc dot gnu.org, | |venkataramanan.kumar at amd dot co | |m Ever confirmed|0 |1 Summary|[5.2/6.0 regression] |[5/6 Regression] |-ftree-loop-if-convert-stor |-ftree-loop-if-convert-stor |es does not vectorize |es does not vectorize |conditional assignment |conditional assignment |(anymore) |(anymore) Target Milestone|--- |6.0 Severity|normal |enhancement --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- This is because in condAssign1 v3 is not accessed always and thus we do not know (ok, stupid ifcvt limitation) that v3[i] is not accessed out-of-bounds. Previous to 2015-07-10 Richard Biener <rguent...@suse.de> PR tree-optimization/66823 * tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix inverted predicate. ifcvt's reasoning was "oh, "v3[i] is _not_ equal to v2[i] which is always accessed, thus it's fine to access it always as well". I fixed this bug but did not try to enhance ifcvts idea of what operations can trap (v3[i] is thought to eventually trap because we do not try to analyze what values 'i' can have). So in 4.9 and earlier this only works becuase of the above bug. So, kind of "confirmed", but it's really an enhancement request. AFAIR Venkat is working in this area.