http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56608



Richard Biener <rguenth at gcc dot gnu.org> changed:



           What    |Removed                     |Added

----------------------------------------------------------------------------

             Status|UNCONFIRMED                 |ASSIGNED

      Known to work|                            |4.6.4

           Keywords|                            |wrong-code

   Last reconfirmed|                            |2013-03-13

         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org

                   |gnu.org                     |

     Ever Confirmed|0                           |1

            Summary|SLP seems to produce        |[4.7/4.8 Regression] SLP

                   |incorrect value with        |seems to produce incorrect

                   |-ffast-math                 |value with -ffast-math

   Target Milestone|---                         |4.7.3

      Known to fail|                            |4.7.3, 4.8.0



--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-13 
09:08:04 UTC ---

Confirmed.  Note we also generate non-optimal code in that we keep both

the vectorized and non-vectorized paths:



  _81 = (int) _80;

  uf_15(D)->autoCropHeight = _81;

...

  _84 = (double) _81;

  _85 = _83 / _84;

  if (aspectRatio_20 < _85)

    goto <bb 9>;

  else

    goto <bb 10>;



  <bb 9>:

  _86 = _84 * aspectRatio_20;

  _87 = _86 + 5.0e-1;

  _88 = __builtin_ifloor (_87);



and vectorized:



  vect_p.26_224 = &uf_15(D)->rotatedHeight;

  MEM[(struct ufraw_data *)vect_p.26_224] = vect_var_.22_217;



instead of re-loading the scalars from the vector.  That is, when

looking for scalar stores we start the SLP instance from we fail to

verify that no uses of the scalars in the instance remain after

vectorization.  Or if they remain, we fail to replace them with

vector extracts.



Not sure yet what's the wrong code issue (nothing obvious yet, still

investigating).

Reply via email to