[Bug target/47989] -mrecip causes 482.sphinx3 and 464.h264ref to miscompare

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.03.04 16:06:42
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
            Summary|-mrecip causes 482.sphinx3  |-mrecip causes 482.sphinx3
                   |to miscompare               |and 464.h264ref to
                   |                            |miscompare
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-04 16:06:42 UTC ---
Similarly 464.h264ref miscompares because of

  fprintf(stdout, "Freq. for encoded bitstream: %1.0f\n",
          img->framerate/(float)(input->jumpd+1));

where both img->framerate and input->jumpd are input parameters
(15.0 and 1).  Here the rounding to integer happens inside fprintf.

Feeding rcps sequences into call stmts is probably never a very good idea.



Mine.  I'm going to move rcps expansion up into tree-ssa-math-opts, the
same place where we apply LCM for CSE-ing 1/x.  Probably replace the
division by a builtin.