[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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?