EricWF closed this revision.
EricWF added a comment.
r268285.
http://reviews.llvm.org/D19623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
EricWF accepted this revision.
EricWF added a comment.
This revision is now accepted and ready to land.
I have no objections to this change. Howard seems to agree.
http://reviews.llvm.org/D19623
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
howard.hinnant added a comment.
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
STL_MSFT added a comment.
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
EricWF added a comment.
*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?
http://reviews.llvm.org/D19623
___
cfe-commits mailing list
cfe-commits@lists.llv
STL_MSFT retitled this revision from "[libc++] Initialize local doubles to
0.0." to "[libcxx] [test] Initialize local doubles to NaN.".
STL_MSFT updated the summary for this revision.
STL_MSFT updated this revision to Diff 55506.
STL_MSFT added a comment.
Now I'm using NaN instead of 0.0 for the
