[cfe-dev] signbit returns false for negative NaN

[Steve (Numerics) Canon]

No problem, thanks for the simple report.

– Steve

On Jun 8, 2014, at 4:09 PM, victor.zverovich at gmail.com wrote:

> Thanks for fixing this.
> 
> - Victor
> 
> 
> On Sat, Jun 7, 2014 at 11:11 PM, Steve (Numerics) Canon <scanon at apple.com> wrote:
> On Jun 6, 2014, at 2:36 PM, Stephen Canon <scanon at apple.com> wrote:
> 
> >> On Jun 6, 2014, at 2:18 PM, Philip Reames <listmail at philipreames.com> wrote:
> >>
> >> On 06/06/2014 01:02 PM, Chandler Carruth wrote:
> >>>
> >>> The standards for C and C++, and consequentially Clang and LLVM, are terribly underspecified w.r.t. things like NaN behavior. =/ We have seen this before, and even if we fix it in Clang/LLVM I worry that it will regress as there are many places where we model NaNs in a manner slightly too aggressive to be strictly IEEE-754 conforming. =[
> >> Is being IEEE-754 conforming a worthwhile goal?  If so, we could talk about how to improve testing to prevent such regressions and find other latent bugs.
> >>
> >> I would generally argue in favour of conformance, but am not familiar with exactly what the C/C++ rules are.
> >
> > C and C++ recommend but do not require IEEE-754 conformance (they define a means for a platform to claim conformance, but do not require that it do so).  At least within Apple, we’ve historically put a fair bit of effort into maintaining IEEE-754 conformance, at least when it comes to the semantics of basic arithmetic in default rounding (like this case does).
> >
> >> To say this differently, are there important optimizations we don't want to loose which aren't conforming?
> >
> > We have relaxed modes (-ffast-math and friends) that license those optimizations.  The default mode should conform as much as reasonably possible.
> 
> This turns out to be a bug in APFloat.  I'll post a patch to llvm-commits in a minute.
> 
> – Steve
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140608/e3d217ec/attachment.html>