Re: Bug related to floating-point traps?

[Gabriel Paubert <paubert at iram dot es>]

On Wed, Jun 15, 2005 at 03:14:59PM +0200, Vincent Lefevre wrote:
> I don't know if this is a bug in gcc or the glibc... Consider the
> following program "traps1":
> 
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <stdlib.h>
> #include <float.h>
> #include <fenv.h>
> 
> int main (int argc, char *argv[])
> {
>   volatile long double x, y = 0.0;
> 
>   if (argc != 3)
>     {
>       fprintf (stderr, "Usage: exception <double> <flag>\n");
>       exit (1);
>     }
> 
>   if (fesetround (FE_DOWNWARD))
>     {
>       fprintf (stderr, "Can't set rounding mode to FE_DOWNWARD\n");
>       exit (1);
>     }
> 
>   x = atof (argv[1]);
>   x *= LDBL_MAX;
>   printf ("x = %Lg\n", x);
>   feenableexcept (FE_OVERFLOW);
>   if (atoi (argv[2]))
>     y += 0.0;
>   return 0;
> }
> 
> 
> I get the following results on X86 and PowerPC processors with gcc 4.0
> (Debian):
>   * x86, traps1 2 0  -> x = 1.18973e+4932
>   * x86, traps1 2 1  -> ditto with floating point exception signal
>   * ppc, both cases  -> x = 1.79769e+308 with FPE signal
> 
> I don't think one should get floating-point exception signals, and in
> any case, the results between both processors seem to be inconsistent.

The exception flags are sticky. So you get the exception because
operations before feenableexcept set the overflow flag.

The  difference is that the PPC triggers the exception as soon
as you unmask the exception while the x86 only checks for
pending exceptions at the beginning of an arithmetic FP instruction. 

That's the dreadful x87 delayed exception mechanism, which 
would require compilers to add fwait to handle exceptions 
in the context in which they occur and not some time later.
For example if the last FP instruction before the return 
from a function produced an exception, the exception will be 
taken whe the caller tries to use the result.

On x86, SSE exception handling is much saner.

	Gabriel