Tcl Source Code

View Ticket
Login
Ticket UUID: 1783544
Title: TclIsNaN may get "optimized away"
Type: Bug Version: obsolete: 8.5.2
Submitter: kot Created on: 2007-08-28 17:33:14
Subsystem: 48. Number Handling Assigned To: kennykb
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2008-03-30 11:40:17
Resolution: Fixed Closed By: kennykb
    Closed on: 2008-03-30 04:40:17
Description:
When compiling on Solaris 10 using the latest Sun Studio 12 compiler (with ``-fast -xO3''), the current implementation of the TclIsNaN macro (generic/tclInt.h:3370 ``((d) != (d))'') gets optimized away and never returns true. This causes things like Tcl_PrintDouble to crash, when passed a NaN number.

The attached patch changes the macro (and the adjacent one) to use the standard ones defined in math.h.

There /could/ be platforms, where these standard macros aren't present -- they would need to be handled separately...
User Comments: kennykb added on 2008-03-30 11:40:17:
Logged In: YES 
user_id=99768
Originator: NO

I think that I now have the correct nastiness in unix/configure.in
to determine whether isnan() is available and use it on the platforms
where it is found.  Windows is a bit simpler; MSVC should use _isnan,
while gcc and icc use the standard isnan(); if anyone has a compiler
that needs the ((d) != (d)) hack, we could add the same junk to the
configurator there, or advise them to -DNO_ISNAN, or to fix their
compiler.

kot added on 2007-09-10 22:55:27:
Logged In: YES 
user_id=173641
Originator: YES

AFAIK, isnan and isinf are both _the_ standard predicates. The current implementation of each is a hack, which may be needed on some platforms lagging behind. The "auto-foo" may be needed for _those_, not the other way around...

As for -fsimpleX -- I tried it in different ways, including the explicit -fsimple1. It did not help. The d != d is, apparently, optimized away as always false long before the nature of the d (being a double) is examined.

I'm aware of the possibility of IEEE 754 non-compliance, but the all of the tests succeed here -- after applying the isnan() patch.

dgp added on 2007-09-05 23:41:04:
Logged In: YES 
user_id=80530
Originator: NO


If there's reliable auto-goo
that can solve this with reasonable
effort, that's ok with me.

Otherwise, I'd have to say that
builders who depart from the
default compiler options are
responsible for the consequences,
and we should so our best to see
that the default options produce
the right thing.

kennykb added on 2007-09-04 03:47:03:
Logged In: YES 
user_id=99768
Originator: NO

From the Sun Studio 12 documentation:

"The –fast option is unsuitable for programs that require strict conformance to the IEEE 754 Standard."

In particular, I see that '-fast' implies '-fsimple=2', which will break NaN behaviour in other areas as well.  We *may* be able to get away with '-fast -fsimple=0' or we may need to enumerate optimization flags specifically.  

Also there unquestionably *are* platforms (at least MSVC prior to VS2005) that fail to implement isnan() correctly.  I'd strongly prefer to do whatever's necessary with the compilation flags.

I don't have a Solaris box to test on any more.  

The standard configurator appears not to include '-fast -xO3' in the flags; does this occur with a stock build, or only when you hack the Makefile?

Don, do you have any further comments here?

kot added on 2007-08-29 00:33:16:

File Added - 243212: tclInt.patch

Attachments: