Re: [PATCH][BZ #5768 fix SIGFPE in isnan(0 for SNaN

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Mon, 2008-02-18 at 19:02 -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 18, 2008 at 05:27:05PM -0600, Steven Munroe wrote:
> > The attached patch fixes a problem we found in PPC where GCC4.1+ code
> > motion rearranges the inline asm macros for isnan(). GCC moves the
> > (x==x) after the original fpscr (with FE_INVALID enabled) is restored.
> > If a Signaling NaN is passed we will get a SIGFPE.
> 
> Isn't moving a potentially trapping computation across a volatile asm
> a gcc bug?
> 
No its just the spread across several macros there is no good way to
define a dependency to prevent this code motion from happening. In the
sequence:

  savedstate = fegetenv_register ();
  reset_fpscr_bit (FPSCR_VE);
  result = !(x == x);
  fesetenv_register (savedstate);
  return result;

the fesetenv_register macro defines inline asm containing the mtfsf
instruction. In this case the asm would need a dependency on "result"
to prevent the code motion. I would have to replace the
fesetenv_register macro with explicit inline asm or define a special
version of fesetenv_register which passes an extra parm for the bogus
dependency.

So this is not a GCC bug. It was just simpler to write the asm code and
get exactly the code I want in the correct sequence.