[Tcl-bugs] [ tcl-Bugs-1783544 ] TclIsNaN may get "optimized away"

[SourceForge.net <no...@so...>]

Bugs item #1783544, was opened at 2007-08-28 13:33
Message generated for change (Comment added) made by kennykb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1783544&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 47. Number Handling
>Group: current: 8.5.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Mikhail Teterin (kot)
Assigned to: Kevin B KENNY (kennykb)
Summary: TclIsNaN may get "optimized away"

Initial Comment:
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...

----------------------------------------------------------------------

>Comment By: Kevin B KENNY (kennykb)
Date: 2008-03-30 00:40

Message:
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.

----------------------------------------------------------------------

Comment By: Mikhail Teterin (kot)
Date: 2007-09-10 11:55

Message:
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.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2007-09-05 12:41

Message:
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.


----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2007-09-03 16:47

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1783544&group_id=10894