[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] Uninitialized variables and signaling NaNs

From: Jochen Küpper
Subject: Re: [Help-gsl] Uninitialized variables and signaling NaNs
Date: Sun, 8 Aug 2010 12:28:22 -0700

Dear Andrew,

On 08.Aug.2010, at 10:12, Andrew W. Steiner wrote:

>     There was recently a big discussion in the D0 collaboration
> at Fermilab about a signaling NaN popping up in uninitialized variables.
> To use some GSL code to demonstrate the issue, I've copied
> some of cdf/cauchyinv.c from 1.14 below (edited to make it compact).
> [I'm not a member of D0 myself and don't have access to their
> code.] The issue is that the optimizer is free to load values in the register
> if it likes, and in particular it may do so with the variable 'x'.
> Unfortunately since x is uninitialized, the value of x is determined
> by whatever happens to be in memory, i.e. it might contain
> a signaling NaN. In that case, a floating point exception is
> triggered and the code crashes. D0 went so far as to contact
> a local member of the C++ standards committee to verify this
> quandary.
>     Obviously one could turn off floating point exceptions, but
> that seems like a bad way to go about things, as it might
> prevent you from missing other errors elsewhere.

Isn't that an issue that should be handled by the optimizer? That's the 
instance that knows whether this issue might occur or not, i.e., it knows 
whether the variable is put into a register or not.

Therefore, the optimizer should initialize this variable if it's put into a 
register (probably using a switch to turn off or on). Obviously, it then has to 
determine whether it is still worth the register usage with the added overhead 
of initialization.

Or would it actually be feasible to use the register (for x) without moving the 
content of &x but instead using whatever happens to be in the register?

>    Thus I'm inclined to think that this code in GSL below,
> and all other code like it should, in principle, be rewritten.
> This is quite a bit of work, however, as there are dozens
> of files in GSL which are susceptible to this kind of failure.
> I'm not suggesting that this needs to be fixed desperately
> but I wanted to post to see if anyone else
> had seen this problem and had some other brilliant
> suggestions. Crowd-sourcing ftw.
> Take care,
> Andrew
> ----------------------------------------------
> double gsl_cdf_cauchy_Pinv (const double P, const double a) {
>  double x;
>  if (P == 1.0) {
>      return GSL_POSINF;
>    } else if (P == 0.0) {
>      return GSL_NEGINF;
>    }
>  if (P > 0.5) {
>      x = a * tan (M_PI * (P - 0.5));
>    } else {
>      x = -a / tan (M_PI * P);
>   }
>   // .. etc etc etc

Einigkeit und Recht und Freiheit      
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        Sex, drugs and rock-n-roll

reply via email to

[Prev in Thread] Current Thread [Next in Thread]