Opened 16 years ago
Closed 16 years ago
#199 closed defect (fixed)
std::isnan() is not available with all compiler
Reported by: | Alpar Juttner | Owned by: | Alpar Juttner |
---|---|---|---|
Priority: | major | Milestone: | LEMON 1.1 release |
Component: | core | Version: | hg main |
Keywords: | Cc: | ||
Revision id: | 04c0631fd332 |
Description
std::isnan()
is not provided by some compiler, such as VS2005 and icc-10.1.
We should provide an own implementation like this:
inline bool isnan(double v) { return v!=v; }
Of course, this function can optionally use std::isnan()
if it is available.
Attachments (2)
Change History (8)
comment:1 follow-up: 2 Changed 16 years ago by
comment:2 follow-up: 3 Changed 16 years ago by
Replying to alpar:
Update on Intel C++:
My previous failure with icc turned out to be a linking problem due to a corrupt installation of icc. At least I could successfully run
make check
on [04c0631fd332] with the 64 bit version of icc, both with version 10.1-021 and 11.0-074. (Although the compilation is extremely slow.)
I find now that it may depend on the gcc version installed (icc uses the gcc header files).
- At the successful compilation above the default gcc version is 4.1.0, so icc probably uses the headers of this version.
- On the other hand on my laptop icc uses the headers of gcc 4.3.2 and emits the following error.
/usr/include/c++/4.3/cmath(540): error: identifier "__builtin_isnan" is undefined return __builtin_isnan(__type(__f)); ^ detected during instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::isnan(_Tp) [with _Tp=double]" at line 600 of "../lemon/lp_base.h" compilation aborted for ../lemon/lp_skeleton.cc (code 2)
Anyway, the attached patch ([03ce6078f568]) resolves this problem both on icc and VS2005. There are some question coming with this patch.
- Applying this patch, lemon will use the custom implementation even if
std::isnan()
is available. Shouldn't we use that one if available? Does is that have any practical advantage of doing that? - Will this own
isnan()
implementation work correctly on all platforms? - Currently, I put this stuff into a separate file (
lemon/bits/isnan.h
). Shouldn't it go into say lemon/core.h instead?
Changed 16 years ago by
Attachment: | 03ce6078f568.patch added |
---|
comment:3 follow-up: 4 Changed 16 years ago by
Replying to alpar:
Replying to alpar:
Update on Intel C++:
My previous failure with icc turned out to be a linking problem due to a corrupt installation of icc. At least I could successfully run
make check
on [04c0631fd332] with the 64 bit version of icc, both with version 10.1-021 and 11.0-074. (Although the compilation is extremely slow.)I find now that it may depend on the gcc version installed (icc uses the gcc header files).
- At the successful compilation above the default gcc version is 4.1.0, so icc probably uses the headers of this version.
- On the other hand on my laptop icc uses the headers of gcc 4.3.2 and emits the following error.
/usr/include/c++/4.3/cmath(540): error: identifier "__builtin_isnan" is undefined return __builtin_isnan(__type(__f)); ^ detected during instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::isnan(_Tp) [with _Tp=double]" at line 600 of "../lemon/lp_base.h" compilation aborted for ../lemon/lp_skeleton.cc (code 2)Anyway, the attached patch ([03ce6078f568]) resolves this problem both on icc and VS2005. There are some question coming with this patch.
- Applying this patch, lemon will use the custom implementation even if
std::isnan()
is available. Shouldn't we use that one if available? Does is that have any practical advantage of doing that?
In the gcc there is a _GLIBCXX_HAVE_ISNAN macro which can indicate whether the isnan function is exists. If the macro is set we can use the gcc version. However, the performance of the two variants with gcc 4.3.3 are quite same.
- Will this own
isnan()
implementation work correctly on all platforms?
I think yes, the only number which differs from itself is the nan.
- Currently, I put this stuff into a separate file (
lemon/bits/isnan.h
). Shouldn't it go into say lemon/core.h instead?
Maybe into the lemon/math.h.
Changed 16 years ago by
Attachment: | 81627fa1b007.patch added |
---|
comment:4 follow-up: 5 Changed 16 years ago by
Replying to deba:
- Currently, I put this stuff into a separate file (
lemon/bits/isnan.h
). Shouldn't it go into say lemon/core.h instead?Maybe into the lemon/math.h.
So I moved it to lemon/math.h81627fa1b007], see [81627fa1b007]. I suggest putting this changeset into the main. What do you think?
Note that LEMON will then use its own implementation even if std::isnan()
is available. We may change it later if we see any good reason for doing so.
comment:5 follow-up: 6 Changed 16 years ago by
Replying to alpar:
Replying to deba:
- Currently, I put this stuff into a separate file (
lemon/bits/isnan.h
). Shouldn't it go into say lemon/core.h instead?Maybe into the lemon/math.h.
So I moved it to lemon/math.h81627fa1b007], see [81627fa1b007]. I suggest putting this changeset into the main. What do you think?
Note that LEMON will then use its own implementation even if
std::isnan()
is available. We may change it later if we see any good reason for doing so.
In my opinion, it can go to the main.
comment:6 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Update on Intel C++:
My previous failure with icc turned out to be a linking problem due to a corrupt installation of icc. At least I could successfully run
make check
on [04c0631fd332] with the 64 bit version of icc, both with version 10.1-021 and 11.0-074. (Although the compilation is extremely slow.)