From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2007-10-18 08:45:13
"John Maddock" <john_at_[hidden]> wrote in message
news:001701c81183$1fd50020$a4f86d51_at_fuji...
> Gennadiy Rozental wrote:
>> Hi, John
>>
>> Can you please take a look on failures today. I've enabled additional
>> error detection within Boost.Test with floating point operations on
>> WIN32 platform. Does theses look valid to you?
>
> Ahhhh! No, there are quite a lot of tests that are expected to return
> infinity, or underflow to zero. Enabling floating point hardware
> exceptions
> will break those: the tests are predicated on
> numeric_limits<>::has_infinity
> etc, but not on the *runtime* value of the hardware exception flags. I
> assume you're calling __control87 somewhere to turn these exceptions on?
switch_fp_exceptions( bool on_off )
{
if( !on_off )
_clearfp();
int cw = ::_controlfp( 0, 0 );
int exceptions_mask =
_EM_INVALID|_EM_DENORMAL|_EM_ZERODIVIDE|_EM_OVERFLOW|_EM_UNDERFLOW;
if( on_off )
cw &= ~exceptions_mask; // Set the exception masks on, turn
exceptions off
else
cw |= exceptions_mask; // Set the exception masks off, turn
exceptions on
if( on_off )
_clearfp();
// Set the control word
::_controlfp( cw, _MCW_EM );
}
> My gut feeling is that this is the wrong moment to introduce a breaking
> change like this, especially as you're changing the compiler's default
> behaviour. Given enough time it's work-aroundable, but it's time I'd
> rather
> not spend just at present, and besides I would expect this to break
> libraries like random and interval as well. If you want to make this an
> option for Boost.Test that's fine, it's making this the default in the run
> up to a release that I'm not happy with.
Ok. How about if I make this optional and disabled by default for now. But
make it enabled by default after 1.35?
Gennadiy