[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.3 Resolution|--- |FIXED Target Milestone|5.0 |4.9.3 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Feb 19 14:13:16 2015 New Revision: 220815 URL: https://gcc.gnu.org/viewcvs?rev=220815root=gccview=rev Log: 2015-02-19 Richard Biener rguent...@suse.de Backport from mainline 2014-12-09 Richard Biener rguent...@suse.de PR middle-end/64199 * fold-const.c (fold_binary_loc): Use TREE_OVERFLOW_P. * gcc.dg/torture/pr64199.c: New testcase. 2015-01-14 Richard Biener rguent...@suse.de PR tree-optimization/64493 PR tree-optimization/64495 * tree-vect-loop.c (vect_finalize_reduction): For double-reductions assign the proper vectorized PHI to the inner loop exit PHIs. * gcc.dg/vect/pr64493.c: New testcase. * gcc.dg/vect/pr64495.c: Likewise. 2015-01-27 Richard Biener rguent...@suse.de PR tree-optimization/56273 PR tree-optimization/59124 PR tree-optimization/64277 * tree-vrp.c (vrp_finalize): Emit array-bound warnings only from the first VRP pass. * g++.dg/warn/Warray-bounds-6.C: New testcase. * gcc.dg/Warray-bounds-12.c: Likewise. * gcc.dg/Warray-bounds-13.c: Likewise. 2015-02-19 Richard Biener rguent...@suse.de Backport from mainline 2015-01-15 Richard Biener rguent...@suse.de PR middle-end/64365 * tree-data-ref.c (dr_analyze_indices): Make sure that accesses for MEM_REF access functions with the same base can never partially overlap. * gcc.dg/torture/pr64365.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/Warray-bounds-12.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/Warray-bounds-13.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr64199.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr64365.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr64493.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr64495.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-data-ref.c branches/gcc-4_9-branch/gcc/tree-vect-loop.c branches/gcc-4_9-branch/gcc/tree-vrp.c
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 30 Jan 2015, brooks at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #13 from Brooks Moses brooks at gcc dot gnu.org --- FWIW, if you haven't done the 4.9 backport yet, this is what I ended up with. I'm not sure it's optimal, but it seems to work. Looks optimal to me - so if you bootstrapped and tested this it is ok to apply to the branch (with the testcase also backported of course). Index: gcc/tree-data-ref.c === --- gcc/tree-data-ref.c (revision 220259) +++ gcc/tree-data-ref.c (working copy) @@ -973,6 +973,24 @@ fold_convert (ssizetype, memoff)); memoff = build_int_cst (TREE_TYPE (memoff), 0); } + /* Adjust the offset so it is a multiple of the access type +size and thus we separate bases that can possibly be used +to produce partial overlaps (which the access_fn machinery +cannot handle). */ + double_int rem; + if (TYPE_SIZE_UNIT (TREE_TYPE (ref)) + TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (ref))) == INTEGER_CST + !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (ref + rem = tree_to_double_int (off).mod +(tree_to_double_int (TYPE_SIZE_UNIT (TREE_TYPE (ref))), false, + TRUNC_MOD_EXPR); + else + /* If we can't compute the remainder simply force the initial + condition to zero. */ + rem = tree_to_double_int (off); + off = double_int_to_tree (ssizetype, tree_to_double_int (off) - rem); + memoff = double_int_to_tree (TREE_TYPE (memoff), rem); + /* And finally replace the initial condition. */ access_fn = chrec_replace_initial_condition (access_fn, fold_convert (orig_type, off)); /* ??? This is still not a suitable base object for
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #12 from Brooks Moses brooks at gcc dot gnu.org --- Thanks, Richard! It looks like I'll need to backport this to our google/gcc-4_9 branch before that happens; any chance you already have a version of this patch that works with 4.9? The wide_int pieces don't exist in 4.9 AFAICT.
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #13 from Brooks Moses brooks at gcc dot gnu.org --- FWIW, if you haven't done the 4.9 backport yet, this is what I ended up with. I'm not sure it's optimal, but it seems to work. Index: gcc/tree-data-ref.c === --- gcc/tree-data-ref.c (revision 220259) +++ gcc/tree-data-ref.c (working copy) @@ -973,6 +973,24 @@ fold_convert (ssizetype, memoff)); memoff = build_int_cst (TREE_TYPE (memoff), 0); } + /* Adjust the offset so it is a multiple of the access type +size and thus we separate bases that can possibly be used +to produce partial overlaps (which the access_fn machinery +cannot handle). */ + double_int rem; + if (TYPE_SIZE_UNIT (TREE_TYPE (ref)) + TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (ref))) == INTEGER_CST + !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (ref + rem = tree_to_double_int (off).mod +(tree_to_double_int (TYPE_SIZE_UNIT (TREE_TYPE (ref))), false, + TRUNC_MOD_EXPR); + else + /* If we can't compute the remainder simply force the initial + condition to zero. */ + rem = tree_to_double_int (off); + off = double_int_to_tree (ssizetype, tree_to_double_int (off) - rem); + memoff = double_int_to_tree (TREE_TYPE (memoff), rem); + /* And finally replace the initial condition. */ access_fn = chrec_replace_initial_condition (access_fn, fold_convert (orig_type, off)); /* ??? This is still not a suitable base object for
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #11 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 22 Jan 2015, brooks at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 Brooks Moses brooks at gcc dot gnu.org changed: What|Removed |Added CC||brooks at gcc dot gnu.org --- Comment #10 from Brooks Moses brooks at gcc dot gnu.org --- Richard, are you expecting to backport this to the 4.9 branch as well? Yes, I will do that after I'm sure there isn't any fallout (that is, it will make the next release at least)
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 Brooks Moses brooks at gcc dot gnu.org changed: What|Removed |Added CC||brooks at gcc dot gnu.org --- Comment #10 from Brooks Moses brooks at gcc dot gnu.org --- Richard, are you expecting to backport this to the 4.9 branch as well? Thanks!
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 --- Comment #9 from Cong Hou congh at google dot com --- Thanks for the fix, Richard!
[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.9/5 Regression] |[4.9 Regression] Predictive |Predictive commoning after |commoning after loop |loop vectorization produces |vectorization produces |incorrect code. |incorrect code. Known to fail|5.0 | --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar (surely latent on the 4.8 branch as well).
