[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[rguenth at gcc dot gnu.org]

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).