octonion_test and quaternion_test failures on Intel 8.1/Windows
Both octonion_test.cpp and quaternion_test.cpp, at about line 94, contain the following: // Provide standard floating point abs() overloads for MSVC //#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || (defined(_MSC_EXTENSIONS) && BOOST_MSVC < 1310) That looks like a workaround for the fact that prior to VC++ 7.1, the Microsoft C library did not define abs(float) etc. if _MSC_EXTENSIONS was defined. The Intel compiler uses the Microsoft libraries, and defines _MSC_EXTENSIONS, but of course BOOST_MSVC is not defined. That causes the workaround code to be included, resulting in multiple definitions, if the Microsoft library 1310 (7.1) or later is being used. I believe the corrected code should read: // Provide standard floating point abs() overloads if older Microsoft // library is used with _MSC_EXTENSIONS defined. This code also works // for the Intel compiler using the Microsoft library. #if defined(_MSC_EXTENSIONS) && defined(_MSC_VER) && _MSC_VER < 1310 I've committed this change to CVS for both source files on the assumption that this suits the library maintainer. If not, or there is something wrong with the fix, please feel free to revert the changes. --Beman
Somewhere in the E.U., le 31/05/2005 Bonjour In article <6.0.3.0.2.20050524220323.037d0c20@mailhost.esva.net>, Beman Dawes <bdawes@acm.org> wrote:
Both octonion_test.cpp and quaternion_test.cpp, at about line 94, contain the following:
[SNIP pb & fix]
I've committed this change to CVS for both source files on the assumption that this suits the library maintainer. If not, or there is something wrong with the fix, please feel free to revert the changes.
--Beman
Thanks for the fix! This of course suits me. I did further modify it in the hope (apparently well-founded) that it would also fix the CW 9 on Intel problem. The remaining outstanding problems with quaternions, octonions and special functions all revolve around "long double" problems which I believe are due to the libstdc++ of these platforms which seem to have some deficiency w.r.t. 64 bits computing (the Beman/Win32/gcc result is odd, though, and will need further investigation). Jonathan Wakely is investigating the matter and in the end, if necessary, I can (but would rather not) disable the test for "long double". A few scattered problems remain as well, COMSOFT apparently fails to define the "float atan(float)" signature (and provides useless output for the quaternion and special functions tests), the FFT-icc 8 results seem irrelevant and SunPro 5 gets tripped by "for_each" (which seems to pulled in somehow...). At worst these can be marked as expected failures. Merci Hubert P.S.: sorry for the rather asinch replies I make to various threads, but things are a bit hectic lately, and I have not even managed to read all I would like to here; should be smoother next month, and definitely better in August :-) (not to mention July, where I'll be almost one month off-line, on vacation :-)) ).
Hubert Holin wrote:
A few scattered problems remain as well, COMSOFT apparently fails to define the "float atan(float)" signature
I did a modification to the compiler toolset which fixes this. The (undocumented) macro __CNAME_OVERLOADS needs to be defined to get all the overloads required by the standard.
(and provides useless output for the quaternion and special functions tests),
This one was due to the fact that during the regression test runs a wrong version of the shared C++ standard library was used. This is due to the fact that several compiler versions are installed side-by-side on the machine. I changed my local toolset to link with the static version of this library. All math tests are now passing on Tru64 with this toolset. Markus
participants (2)
-
Beman Dawes -
Hubert Holin -
Markus Schöpflin