Tom, I have some experience with FPEs under Delphi, and what I came to learn is that most of the time, the exception occurs somewhere before what is reported, due to "Imprecise Trapping Modes". In short, "this means the hardware can detect a floating-point exception and deliver an interrupt, but processing may continue while the signal is delivered. As a result, the instruction address register (IAR) is at a different instruction when the interrupt is delivered." (taken from http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/floating-point_except.htm).
They can be extremely vexing to solve - good luck! Alan On Sun, Aug 24, 2008 at 3:42 PM, Tom Verhoeff <[EMAIL PROTECTED]> wrote: > On Sat, Aug 23, 2008 at 12:20:48AM +0200, Tom Verhoeff wrote: > > I have an application (for optimizing decisions in the dice game Yahtzee) > > that uses Real and runs well with FPC on Mac OS X (PPC), but that > > fails with a Floating Point Exception (FPE) under Windows (FPC 2.2.0). > > I "played" around some more to resolve this problem. > > It now _seems_ to work, after suppressing all FPU exceptions through > SetExceptionMask in unit Math. > > This is hardly satisfactory, since the place where the program got > interrupted (viz. if x < 0) cannot cause an exception, as far as I > can tell, since x is confirmed to equal -1 at that point. > > So, the program now runs (but might misbehave). > > I'll keep you posted. > > Tom
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
