Hi, The Boost.Trunk summary now gives for some Intel compilers, since some time: Test output: Sandia-intel-10.1 - geometry - distance / intel-darwin-10.1Rev 70458 / Wed, 23 Mar 2011 01:41:17 +0000 Report Time: Thu, 24 Mar 2011 07:47:34 +0000 Compile [2011-03-23 04:42:50 UTC]: fail "/opt/intel/cce/10.1.024/bin/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -D__WINT_TYPE__=int -I".." -I"../boost/geometry/extensions/contrib/ttmath" -I"../libs/geometry/test" -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/geometry/test/algorithms/distance.test/intel-darwin-10.1/debug/distance.o" "../libs/geometry/test/algorithms/distance.cpp" ../boost/detail/fenv.hpp(11): catastrophic error: #error directive: This platform does not have a floating point environment #error This platform does not have a floating point environment ^ compilation aborted for ../libs/geometry/test/algorithms/distance.cpp (code 4) Meaning the boolean variable BOOST_NO_FENV_H is not set. Is that compiler-detection broken somehow? It is not on all Intel compilers. Regards, Barend
#error This platform does not have a floating point environment ^ compilation aborted for ../libs/geometry/test/algorithms/distance.cpp (code 4)
Meaning the boolean variable BOOST_NO_FENV_H is not set.
Is that compiler-detection broken somehow? It is not on all Intel compilers.
It's the other way around - I changed Boost.Config to set BOOST_NO_FENV_H for Intel prior to 12.0 because it fails the test case (calls to fenv.h functions seem to pretty much always return an error code - it's not at all clear that fenv.h is really working for that compiler). Unfortunately this broke Boost.Test.... but I also committed a fix for that yesterday, so hopefully all will be back to normal soon! Apologies for the problem, John.
On Thu, 24 Mar 2011 10:44:24 -0000, John Maddock wrote:
#error This platform does not have a floating point environment ^ compilation aborted for ../libs/geometry/test/algorithms/distance.cpp (code 4) Meaning the boolean variable BOOST_NO_FENV_H is not set. Is that compiler-detection broken somehow? It is not on all Intel compilers.
It's the other way around - I changed Boost.Config to set BOOST_NO_FENV_H for Intel prior to 12.0 because it fails the test case (calls to fenv.h functions seem to pretty much always return an error code - it's not at all clear that fenv.h is really working for that compiler). Unfortunately this broke Boost.Test.... but I also committed a fix for that yesterday, so hopefully all will be back to normal soon! Apologies for the problem, John. OK, no problem for me. I'll denote this compiler as unsupported then. Thanks, Barend
It's the other way around - I changed Boost.Config to set BOOST_NO_FENV_H for Intel prior to 12.0 because it fails the test case (calls to fenv.h functions seem to pretty much always return an error code - it's not at all clear that fenv.h is really working for that compiler). Unfortunately this broke Boost.Test.... but I also committed a fix for that yesterday, so hopefully all will be back to normal soon! Apologies for the problem, John.
OK, no problem for me. I'll denote this compiler as unsupported then.
Is there a fallback for systems with no fenv.h? If so the right thing to do is to check for BOOST_NO_FENV_H before including the detail/ header (not sure what use the detail/ header is in that case, but there you go...) John.
Hi, I mailed this: On 24-3-2011 11:20, barend wrote:
Hi,
The Boost.Trunk summary now gives for some Intel compilers, since some time:
Test output: Sandia-intel-10.1 - geometry - distance / intel-darwin-10.1Rev 70458 / Wed, 23 Mar 2011 01:41:17 +0000
Report Time: Thu, 24 Mar 2011 07:47:34 +0000
Compile [2011-03-23 04:42:50 UTC]: fail "/opt/intel/cce/10.1.024/bin/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -D__WINT_TYPE__=int -I".." -I"../boost/geometry/extensions/contrib/ttmath" -I"../libs/geometry/test" -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/geometry/test/algorithms/distance.test/intel-darwin-10.1/debug/distance.o" "../libs/geometry/test/algorithms/distance.cpp" ../boost/detail/fenv.hpp(11): catastrophic error: #error directive: This platform does not have a floating point environment
And John responded
It's the other way around - I changed Boost.Config to set BOOST_NO_FENV_H for Intel prior to 12.0 because it fails the test case
and:
Is there a fallback for systems with no fenv.h?
If so the right thing to do is to check for BOOST_NO_FENV_H before including the detail/ header (not sure what use the detail/ header is in that case, but there you go...)
Is this change reverted? Because it is now working again properly for Sandia-intel-10.1 , Sandia-intel-11.0. So, great. The only platform that fails now is Sandia-intel-11.1, giving me at runtime signal: SIGSEGV, si_code: 0 (memory access violation at address: 0x00000000) (this probably is related to the earlier problem). I've seen this earlier, it is not new. I'll probably denote only compiler-version as unsupported then. Regards, Barend
If so the right thing to do is to check for BOOST_NO_FENV_H before including the detail/ header (not sure what use the detail/ header is in that case, but there you go...)
Is this change reverted? Because it is now working again properly for Sandia-intel-10.1 , Sandia-intel-11.0.
No still in Trunk. John.
On 26-3-2011 18:46, John Maddock wrote:
If so the right thing to do is to check for BOOST_NO_FENV_H before including the detail/ header (not sure what use the detail/ header is in that case, but there you go...)
Is this change reverted? Because it is now working again properly for Sandia-intel-10.1 , Sandia-intel-11.0.
No still in Trunk.
OK, thanks. So I don't understand why it was marked as failed for this reason, and now automagically succeeds for it (didn't do anything in between...). Anyway, it works. Barend
participants (3)
-
barend -
Barend Gehrels
-
John Maddock