Wed, 06/24/2015 - 13:23
Forums:
When floating point exceptions are not masked I sometimes get such exceptions when working with OCCT.
Is this to be expected, e.g. because of OpenGL or is it considered a bug?
Is it recommended to mask these exceptions in debug and release mode? Or should they be masked only in release mode for performance reasons?
Mon, 06/29/2015 - 15:50
Dear Timo,
By default (i.e. if the code has been compiled with Visual C++/gcc using default flags), all FP exceptions are masked. With that, any abnormal operations (such as division by zero, square root of negative number,…) will not cause any signal/exception and the operation will gracefully continue. For example, such situation may happen when a SIMD operation working on a vector register (e.g. xmm or ymm) is applied to a vector which does not have all components initialized (i.e. only partially loaded).
Of course, correctness will largely depend on input data, correctness of invoked operations and robustness to abnormal values. For instance, in the above example, the invalid result in the uninitialized part of the vector register will be simply ignored and the operation will safely continue.
To unmask FP exceptions, OCC offers OSD::SetSignal (Standard_True), which installs other signal/exception handlers (e.g. for memory access violations). Note that this only installs the handlers for the current thread. CAD Exchanger SDK offers its own scope-based class which propagates the handlers across worker threads and restores previous handlers upon scope exit.
(Un)masking FP exceptions as well as setting other handlers should be done at the application level. Whether or not to mask is at the app developer discretion. For instance, CAD Exchanger GUI masks the FP exceptions due to some FP exceptions otherwise happening inside the NVidia driver. Probably this is very much similar to what you observe.
Hope this will be some help.
Roman
Mon, 06/29/2015 - 19:24
Dear Timo,
From our point of view it is worth to unmask floating-point errors in your application if it allows to detect errors in application code. But it would be better to keep them masked if errors are produced by system code that you cannot debug or change.
In the past, our practice was to enable floating point exceptions in customer applications; that allowed handling errors more robustly.
However, in more modern applications it turns to be not practical, for different reasons:
- As already mentioned, some graphic drivers tend to trigger FPE even on apparently valid input data
- Applications running in .Net environment will trigger FPE even on simple operations (like assignment of real value to decimal number variable)
- Intel compiler with default option /fp=fast will generate code causing FPE
For this reason, our current practice is not to enable floating point signals in applications.
We have even unmasked them in DRAW in OCCT 6.8.0 (see issue #24589).
However, now we recognize that having no FPE handling in tests may cause some bad code to penetrate OCCT, thus will likely re-enable this in 7.0 (see #26329).
This shall depend on compiler version and perhaps graphic driver; the exact conditions are still to be figured out basing on experiments.
Best regards
FSR