Boost logo

Boost :

From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2004-01-17 04:21:34


Le mar 13/01/2004 à 23:47, Jens Maurer a écrit :
> A compiler vendor contacted me because his x86 compiler
> has sizeof(long double) == 8, so force_rounding cannot
> be a no-op for the "long double" case. (My name is at
> the top of the x86_rounding_control.hpp file, so he
> contacted me.)
>
> I've checked in the following fix to the CVS main
> branch. Could the interval developers please verify
> the correctness of the fix and, if correct, consider
> forwarding the fix to the release branch?
>
> Thanks.
>
> Jens Maurer

Sorry for this late reply, I didn't have access to my Boost repository
this week.

The fix seems correct to me, but I'm not sure I like it. As Sylvain
pointed it out to me, changing the return type is not the best thing to
do. I benchmarked it with a small test (only subtractions) compiled with
GCC (-O3 optimization). And it shows a huge performance drop when using
interval<long double>: 70% slower!

So I'm obviously against forwarding this fix to the release branch. What
is this compiler? I would rather create a new specific rounding file for
it or use a template indirection to select the version depending on
sizeof(long double) value.

Regards,

Guillaume

> diff -u -r1.6 x86_rounding_control.hpp
> --- x86_rounding_control.hpp 30 May 2003 13:54:58 -0000 1.6
> +++ x86_rounding_control.hpp 13 Jan 2004 22:39:52 -0000
> @@ -82,7 +82,17 @@
> template<>
> struct rounding_control<long double>: detail::x86_rounding_control
> {
> - static const long double& force_rounding(const long double& r) { return r; }
> + static long double force_rounding(const long double& r)
> + {
> + // Some compilers use "double == long double", so we may need to
> + // round (from FPU registers into memory) in this case as well.
> + if(sizeof(long double) > 8) {
> + return r;
> + } else {
> + volatile long double r_ = r;
> + return r_;
> + }
> + }
> };
>
> } // namespace interval_lib


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk