Floating Point Exception Handling

Floating Point Exception Handling

[John L. Kulp]

I'd like to get connected with whomever is working on topics like the
interaction between SIGFPE handlers and try/catch stack unwinding in
C++.

In particular, I've seen several implementations of SIGFPE handlers that
throw to try/catch receivers, but they all seem to have problematic
behavior.  In particular, interactions between 387 vs SSE floating
point, libc routines, cpu architecture differences, -ffpmath=sse,387
mode, compiler optimization behavior, etc.  I've experimented (3.3.3)
with some test programs written by others and modified by me that
demonstrate a wide range of incorrect or unexpected behaviors (commonly,
program aborts).  Now some of this may be the need to know some magic
like -fnon-call-exceptions and -fno-omit-frame-pointers, but I'm looking
discuss with people knowledgeable about this topic and who are actively
working in these areas.  By the way, the Intel compiler seems to be more
robust in addressing these issues currently, and I'd like to see g++
(which I use) catch up.  I'd also like to port from x86/SSE to
G5/Alitvec someday with a common code base, which is another reason to
stay in the g++ universe.

Thanks.

Re: Floating Point Exception Handling

[Jim Wilson]

John L. Kulp wrote:
> I'd like to get connected with whomever is working on topics like the
> interaction between SIGFPE handlers and try/catch stack unwinding in
> C++.

There are few people expert in this area, and they are all very busy 
people.  There may not be anyone who has time to help you.

Unwinding from signal handlers should work fine for any IA-64 target. 
For other targets, it is probably iffy.  Our EH support was designed for 
C++ which does not need this.  It has been expanded to support Java 
which does need this, but this requires special options 
(-fnon-call-exceptions), and probably still needs more work to handle 
all cases.

You might try looking at the optional libunwind package.  This was 
primarily written to support IA-64 target, but it also has some support 
for gcc's DWARF2 CFI based unwinders.  Also, you might find other people 
interested in the same topic on the libunwind mailing list.  See
	http://www.hpl.hp.com/research/linux/libunwind/
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Floating Point Exception Handling

[Joe Buck]

John L. Kulp wrote:
> > I'd like to get connected with whomever is working on topics like the
> > interaction between SIGFPE handlers and try/catch stack unwinding in
> > C++.

On Tue, Mar 30, 2004 at 05:45:27PM -0800, Jim Wilson wrote:
> There are few people expert in this area, and they are all very busy 
> people.  There may not be anyone who has time to help you.

It would require rather deep surgery, I think, to make this work.  G++
is not currently designed around the assumption that any floating point
instruction might throw an exception, which is pretty much what you would
need for such an idea to work.  It's probably a better idea to use
non-signaling Inf and NaN values, test for them at appropriate points and
explicitly throw exceptions.

Re: Floating Point Exception Handling

[Andrew Haley]

Jim Wilson writes:
 > John L. Kulp wrote:
 > > I'd like to get connected with whomever is working on topics like the
 > > interaction between SIGFPE handlers and try/catch stack unwinding in
 > > C++.

I suppose the person with the most experience with unwinding and
signal handlers would be me.

 > There are few people expert in this area, and they are all very busy 
 > people.  There may not be anyone who has time to help you.
 > 
 > Unwinding from signal handlers should work fine for any IA-64 target. 
 > For other targets, it is probably iffy.  Our EH support was designed for 
 > C++ which does not need this.  It has been expanded to support Java 
 > which does need this, but this requires special options 
 > (-fnon-call-exceptions), and probably still needs more work to handle 
 > all cases.

I'm not aware of any current problems with unwinding from SIGFPE
handlers.  However, we don't actually do this on many gcj targets
because we haven't made it a big priority.  

Andrew.