Re: [boost] Boost.config limits_test testcase and qnan checks

Subject: Re: [boost] Boost.config limits_test testcase and qnan checks
From: Matthew Markland (markland_at_[hidden])
Date: 2012-07-17 14:48:31

Extra text elided below:
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-
> bounces_at_[hidden]] On Behalf Of boost-request_at_[hidden]
> Sent: Friday, July 13, 2012 10:51 PM
> To: boost_at_[hidden]
> Subject: Boost Digest, Vol 3701, Issue 4
>----- <elided> 
> Message: 5
> Date: Fri, 13 Jul 2012 18:07:45 +0000
> From: Thomas Klimpel <Thomas.Klimpel_at_[hidden]>
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Subject: Re: [boost] Boost.config limits_test testcase and qnan
> 	checks.
> Message-ID:
> 	<4468C9C2AE594745A32DC93C799A224A01D0FB_at_DE02WEMBX2.inte
> rnal.synopsys.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
<elided>
MARKLAND> My question is whether it is valid to test the qnan behavior when a
MARKLAND> platform
MARKLAND> > does not claim compliance?
> 
> I wonder how you measure "claim compliance"? I once had a long debug
> session with gcc-4.5.2 before I found out that the builtin "is_nan" was
> returning wrong results. Isn't compiling the code that uses "is_nan" without
> warning also some sort of "compliance claim"? I know you are probably
> referring to "numeric_limits<double>::is_iec559", but on which floating point
> functionality can I still rely as a programmer if (is_iec559 == false)?
> 
> Regards,
> Thomas

I've now been trying to come up with a good answer to this for days and have yet to get there.  So I'm going to just comment and see if the discussion continues.  These are my interpretations and should not be construed as the opinion of my employer.

In the case of this particular test, from a language perspective, I think the check for is_iec559 makes sense.  The part of the test in question is testing a behavior that is only defined for certain if the platform is using an IEEE compliant implementation.  Now this doesn't mean that it won't work for a platform that sets is_iec559() to false, but to me it is only guaranteed if is_iec559() is true.

As for what you can rely on if is_iec559() is false, that is a good question.  Most of the items in numeric_limits<> appear to require explicit checks for availability if is_iec559() is false.  My readings of the Standards (C/C++) seem to show them to be silent on what happens with a function like isnan() if is_iec559() is false.  Most of what I've seen on the web is that these functions are of dubious usefulness due to optimizations performed.  Clearly one would like to expect that if the compiler is being used at an optimization level that breaks floating-point compliance then is_iec559() would be set to false, but from what I've read that isn't a safe expectation.  I guess you're at the mercy of your compiler vendor to describe their levels of support and what these functions may mean. 

Does anyone else have insight into this situation?

Matt