Boost.Numeric.Interval: Please specify rounding control mechanism.
Hello, even with the release candidate for 1_34 I get this error message c:/Boost/include/boost-1_34\boost/numeric/interval/hw_rounding.hpp(38) : fatal error C1189: #error : Boost.Numeric.Interval: Please specify rounding control mechanism. on AMD Turion with XP 64 and VC 2005. Can anybody fix this or give a hint what I have to find out on mt platform to fix it. thanks, andreas
Quoting Andreas Fabri:
even with the release candidate for 1_34 I get this error message
c:/Boost/include/boost-1_34\boost/numeric/interval/hw_rounding.hpp(38) : fatal error C1189: #error : Boost.Numeric.Interval: Please specify rounding control mechanism.
on AMD Turion with XP 64 and VC 2005.
Can anybody fix this or give a hint what I have to find out on mt platform to fix it.
I have access neither to this processor nor to this operating system nor to this compiler, so it's a bit complicated to tell you how to fix it. Can you tell me on which FPU (x87, SSE2, 3Dnow) the floating-point computations are executed on your platform? If your platform supports the C99 fenv.h rounding control, then you don't have to know the FPU, you can just modify the hw_rounding.hpp file at line 28 by adding a check for a macro identifying your system. Please report to this mailing-list which macro you used so that other users can benefit from it and I can put it into CVS. If your platform uses the x87 instruction set, then the situation is similar, but this time at line 20. Though it would surprise me if that is the case, as the x87 part was kind of deprecated with the arrival of the x86-64 architecture (when you say "XP 64", it means your processor is 64bit, right?). If your platform relies on another FPU, then you will have to look at how to manually control the rounding direction for it. You can take a look at the {x86,ppc,sparc}_rounding_control.hpp files to see how the FPU is handled on other architectures. Once again, please post the resulting file on this mailing-list so that it can be included. Best regards, Guillaume
Guillaume Melquiond wrote:
Quoting Andreas Fabri:
even with the release candidate for 1_34 I get this error message
c:/Boost/include/boost-1_34\boost/numeric/interval/hw_rounding.hpp(38) : fatal error C1189: #error : Boost.Numeric.Interval: Please specify rounding control mechanism.
on AMD Turion with XP 64 and VC 2005.
Can anybody fix this or give a hint what I have to find out on mt platform to fix it.
I have access neither to this processor nor to this operating system nor to this compiler, so it's a bit complicated to tell you how to fix it. Can you tell me on which FPU (x87, SSE2, 3Dnow) the floating-point computations are executed on your platform?
If your platform supports the C99 fenv.h rounding control, then you don't have to know the FPU, you can just modify the hw_rounding.hpp file at line 28 by adding a check for a macro identifying your system. Please report to this mailing-list which macro you used so that other users can benefit from it and I can put it into CVS.
I believe _M_X64 might be the right macro here (but Andreas needs to check as I don't have a Win64 platform either). I'm not completely sure but I believe this platform depricates the x87 instruction set in favour of the SSE registers, in case that makes any difference, again Andreas would have to take a look at the compilers assembly output to figure that one out. BTW I believe recent Intel Win32 compiler releases do the same thing for x86 as well (which is to say they don't use the x87 instructions just the SSE ones). But maybe someone more knowledgable will step in and comfirm this: or maybe it makes no difference? HTH, John.
John Maddock wrote:
Guillaume Melquiond wrote:
Quoting Andreas Fabri:
even with the release candidate for 1_34 I get this error message
c:/Boost/include/boost-1_34\boost/numeric/interval/hw_rounding.hpp(38) : fatal error C1189: #error : Boost.Numeric.Interval: Please specify rounding control mechanism.
on AMD Turion with XP 64 and VC 2005.
Can anybody fix this or give a hint what I have to find out on mt platform to fix it. I have access neither to this processor nor to this operating system nor to this compiler, so it's a bit complicated to tell you how to fix it. Can you tell me on which FPU (x87, SSE2, 3Dnow) the floating-point computations are executed on your platform?
Hi Guillaume, It's the AMD 64 bit processor. They are called Athlon, and Turion is the mobile version of it. See http://en.wikipedia.org/wiki/Athlon_FX XP64 is the 64 bit Operating system. VC2005 on this hardware/OS can produce 32 bit code as well as 64 bit code. I just checked and can confirm that the macro _M_X64 is defined, whatever that means for you.
If your platform supports the C99 fenv.h rounding control,
There is no file with such a name, and Microsoft told me earlier to have a look at "ANSI _controlfp (specifcally see the _MCW_RC mask) or numeric_limits::round_style, if you're using STL." From newsgroup: https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=435927&SiteID=1 Maybe this helps you to guide me. then you
don't have to know the FPU, you can just modify the hw_rounding.hpp file at line 28 by adding a check for a macro identifying your system. Please report to this mailing-list which macro you used so that other users can benefit from it and I can put it into CVS.
I believe _M_X64 might be the right macro here (but Andreas needs to check as I don't have a Win64 platform either). I'm not completely sure but I believe this platform depricates the x87 instruction set in favour of the SSE registers, in case that makes any difference, again Andreas would have to take a look at the compilers assembly output to figure that one out.
BTW I believe recent Intel Win32 compiler releases do the same thing for x86 as well (which is to say they don't use the x87 instructions just the SSE ones). But maybe someone more knowledgable will step in and comfirm this: or maybe it makes no difference?
I also have the Intel 9 compiler for (32 bit) Windows. Let me know when you want me to check something for you. andreas
HTH, John.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Quoting Andreas Fabri:
VC2005 on this hardware/OS can produce 32 bit code as well as 64 bit code. I just checked and can confirm that the macro _M_X64 is defined, whatever that means for you.
"ANSI _controlfp (specifcally see the _MCW_RC mask) or numeric_limits::round_style,
numeric_limits::round_style could have been a good idea, but the linked
documentation explicitly says it doesn't work, so I'm not sure why it was
suggested to you.
_controlfp does help though (even if the documentation says it's deprecated).
The documentation does not say whether it's an alias for _control87 or not. If
it is, you just have to add "|| defined(_M_X64)" at hw_rounding.hpp:28.
If this is not sufficient, you also have to change all the occurrences of
_control87 by _controlfp in the detail/msvc_rounding_control.hpp file. You can
check your changes by verifying that the following testcase displays "Rounded
outwards".
//-----------------------------------------------
#include <iostream>
#include
I also have the Intel 9 compiler for (32 bit) Windows. Let me know when you want me to check something for you.
Please try the testcase with this compiler too. Best regards, Guillaume
Quoting John Maddock:
BTW I believe recent Intel Win32 compiler releases do the same thing for x86 as well (which is to say they don't use the x87 instructions just the SSE ones). But maybe someone more knowledgable will step in and comfirm this: or maybe it makes no difference?
It makes a big difference for the interval library. For performance reason, the library tries to setup only the coprocessor that will perform the floating-point computations. So if its assumptions are wrong, computations will be performed on a coprocessor that was not properly configured. In contrast, the fesetround C99 function usually reads and writes the control register of every coprocessor. Needless to say, that will bring the machine to a halt, that's why the library tries to avoid it as much as possible (not withstanding the fact that it is not available everywhere). Best regards, Guillaume
participants (3)
-
Andreas Fabri -
Guillaume Melquiond -
John Maddock