This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 25 Oct 2017 08:09:15 +0000
- Subject: [Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)
- Auto-submitted: auto-generated
- References: <bug-82703-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82703
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-10-25
Component|tree-optimization |target
Known to work| |6.3.1
Target Milestone|--- |7.3
Summary|Wrong addition of |[7/8 Regression] Wrong
|std::array components with |addition of std::array
|-O2 -ftree-loop-vectorize |components with -O2
|-ftree-slp-vectorize (works |-ftree-loop-vectorize
|fine with -O2) |-ftree-slp-vectorize (works
| |fine with -O2)
Ever confirmed|0 |1
Known to fail| |7.1.0, 7.2.1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed on GCC 7 branch head. It seems to work on trunk, so maybe a dup...
(but reduction vectorization got a rewrite).
We seem to need both loop and SLP vectorization to trigger the issue:
bug.cpp:18:24: note: loop vectorized
bug.cpp:48:5: note: basic block vectorized
interesting.
dumps show
bug.cpp:57:10: note: basic block part vectorized
bug.cpp:48 is not vectorized.
tree optimization ends up with
<bb 2> [75.00%]:
MEM[(struct &)&v1] ={v} {CLOBBER};
MEM[(double *)&v1] = { 1.0e+0, 2.0e+0 };
MEM[(double *)&v1 + 16B] = 3.0e+0;
res = v1;
vect__15.65_51 = MEM[(value_type &)&res];
vect__16.66_52 = vect__15.65_51 + { 3.0e+0, 2.0e+0 };
MEM[(value_type &)&res] = vect__16.66_52;
_7 = MEM[(value_type &)&res][2];
_91 = _7 + 1.0e+0;
MEM[(value_type &)&res][2] = _91;
v3 = res;
res ={v} {CLOBBER};
compare (&v3, &vref);
which does look ok to me.
It's STV. Adding -fdbg-cnt=stv_conversion:0 to disable STV fixes things.
Confirmed.
Not sure if really fixed on trunk or latent (don't remember STV fixes there).