Re: [glean-dev] catching FP exceptions in C++

[Keith W. <ke...@tu...>]

Brian Paul wrote:
> Allen Akin wrote:
> 
>> On Tue, Nov 08, 2005 at 04:08:19PM -0700, Brian Paul wrote:
>> | I'm going to be writing a new glean test to see how OpenGL handles | 
>> infinite/nan/denorm/etc floating point values.
>>
>> You're a braver man than I am. :-)
>>
>> | My experience with exception handling in C++ is pretty slim and I'm 
>> | not even sure if there's a standard way to handle them.
>>
>> I'm not either.  I've checked my printed references and done a few web
>> searches, and I haven't found anything that claims to work universally.
>>
>> I suspect the most portable thing we could do would be to use the C99
>> standard IEEE exception mechanism.  (See "man fetestexcept", etc.)  It
>> depends on the ANSI C signal-catching utilities, but nothing
>> *nix-specific as far as I can tell.
>>
>> However, I don't have any experience with it, so I don't know for sure
>> that it'll do the job.
> 
> 
> Thanks, Allen.  I wasn't even aware of those functions.
> 
> I'm checking in what I have so far.  There's no attempt at trapping 
> exceptions yet.
> 
> Both Mesa and NVIDIA's driver pass the test in that FP exceptions aren't 
> raised by default.  If I enable FP exceptions in Mesa with export 
> MESA_DEBUG=FP things blow up as soon as I do this assignment:
> 
> 285:        v[1][0] = make_signaling_nan();
> 
> I guess the various make_*() functions should take a pointer to the 
> destination float and store the bit pattern as an integer to avoid 
> blowing up in Glean before we even get into OpenGL.

It does make me question whether having the traps enabled is going to work - if 
you can't even handle the values without provoking an exception, it would mean 
that all the gl entrypoints will also provoke the exceptions.  You may get out 
of glean, but you'll get caught in the libGL.so dispatch functions...

Keith