<div dir="ltr">Tom,<br><br>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 <a href="http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/floating-point_except.htm">http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/floating-point_except.htm</a> ).<br>
<br>They can be extremely vexing to solve - good luck!<br><br>Alan<br><br><div class="gmail_quote">On Sun, Aug 24, 2008 at 3:42 PM, Tom Verhoeff <span dir="ltr"><<a href="mailto:T.Verhoeff@tue.nl">T.Verhoeff@tue.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Sat, Aug 23, 2008 at 12:20:48AM +0200, Tom Verhoeff wrote:<br>
> I have an application (for optimizing decisions in the dice game Yahtzee)<br>
> that uses Real and runs well with FPC on Mac OS X (PPC), but that<br>
> fails with a Floating Point Exception (FPE) under Windows (FPC 2.2.0).<br>
<br>
I "played" around some more to resolve this problem.<br>
<br>
It now _seems_ to work, after suppressing all FPU exceptions through<br>
SetExceptionMask in unit Math.<br>
<br>
This is hardly satisfactory, since the place where the program got<br>
interrupted (viz. if x < 0) cannot cause an exception, as far as I<br>
can tell, since x is confirmed to equal -1 at that point.<br>
<br>
So, the program now runs (but might misbehave).<br>
<br>
I'll keep you posted.<br>
<br>
        Tom</blockquote></div><br></div>