https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #6)
> The reason for the miscompile popping up is this change from the previous
> patch
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
> index 109d4ce5192..df3eab2e8d5 100644
> --- a/gcc/tree-vect-data-refs.cc
> +++ b/gcc/tree-vect-data-refs.cc
> @@ -725,8 +725,7 @@ vect_analyze_early_break_dependences (loop_vec_info
> loop_vinfo)
> bounded by VF so accesses are within range. We only need to
> check the
> reads since writes are moved to a safe place where if we get
> there we
> know they are safe to perform. */
> - if (DR_IS_READ (dr_ref)
> - && !ref_within_array_bound (stmt, DR_REF (dr_ref)))
> + if (!ref_within_array_bound (stmt, DR_REF (dr_ref)))
> {
> if (dump_enabled_p ())
> dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>
> but this should have bee safe, as the stores shouldn't be done until the
> point we know for sure they would be safe to do.
>
> the code out of the vectorizer looks ok to me. Valgrind is saying we're
> reading uninitialized values. But those values I think come from a previous
> look which sets them to 0. Or is supposed to. So working my way up this
> giant function.
Hmm, but there isn't really a "safe" place, is there? If there's a safe
place then it would be safe for reads as well, no?
So I guess when you manage to massage the testcase to be based on decls
then you instead (with the above suggested change) get spurious stores?
