This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Initialize local doubles to NaN.

Authored by STL_MSFT on Apr 27 2016, 2:31 PM.



[libcxx] [test] Initialize local doubles to NaN.

Fixes MSVC "warning C4701: potentially uninitialized local variable 'meow' used".

Diff Detail

Event Timeline

STL_MSFT updated this revision to Diff 55321.Apr 27 2016, 2:31 PM
STL_MSFT retitled this revision from to [libc++] Initialize local doubles to 0.0..
STL_MSFT updated this object.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.
rsmith added a subscriber: rsmith.Apr 27 2016, 2:44 PM

I don't know how the libc++ folks feel about this, but our usual policy in Clang and LLVM is that we don't add bogus initializers to shut up incorrect "maybe used uninitialized" compiler warnings, because these initializers prevent tools like MSan and valgrind from catching the bug if the variable ever is actually used uninitialized. For this reason, we turn off the portion of GCC's -Wuninitialized warning that has false positives too.

I'd be happy to deal with this in another way. Would you accept _MSC_VER-guarded pragmas to silence such warnings? I didn't see an easy way to rework the logic here so that the variables are obviously initialized on every codepath, which would be the ideal pragma-less solution.

When in doubt, I find initializing to nan a safe thing to do. Either the code is correct, or the nan will find the bug.

STL_MSFT updated this revision to Diff 55506.Apr 28 2016, 5:07 PM
STL_MSFT retitled this revision from [libc++] Initialize local doubles to 0.0. to [libcxx] [test] Initialize local doubles to NaN..
STL_MSFT updated this object.

Now I'm using NaN instead of 0.0 for the initializations, as suggested by Howard.

EricWF edited edge metadata.Apr 28 2016, 6:32 PM

*disclaimer* I have no idea what I'm talking about.

Is there any reason why using signalling NaN would be better than quiet NaN in this case?

According to my equally vague understanding, a quiet NaN (if used in operations, instead of being overwritten with something valid) will silently propagate down to the assert, which will complain that it's not equal to whatever you were expecting. That would detect any unintentional use of the NaN-initialized value.

A signaling NaN will (I think) raise an FP exception when you try to do anything with it, which may not be treated similarly by your test harness. (I'm not a good person to answer this question, as C1XX has bug/limitations with returning signaling NaNs, to the point where this function in numeric_limits is essentially useless.)

A quiet nan is the right tool. A signaling nan is nothing more than a 40-year-old design flaw. A quiet nan is "sticky" in that if you try to compute with it, the result is quiet nan. But you can assign a valid number to something containing a quiet nan. So if your answer has nans in it, you know you didn't initialize something properly somewhere.

EricWF accepted this revision.May 2 2016, 12:24 PM
EricWF edited edge metadata.

I have no objections to this change. Howard seems to agree.

This revision is now accepted and ready to land.May 2 2016, 12:24 PM
EricWF closed this revision.May 2 2016, 12:29 PM