[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
Greetings,
Jochen
--
Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de
Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D
Sex, drugs and rock-n-roll