[fpc-pascal] Strange Floating Point Exception problem

[Tom Verhoeff]

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).

What makes things complicated, is that the program has a GUI
through Lazarus, and that it is rather biggish, making it difficult
to isolate the problem.

The place where it complains is a simple statement

  if x < 0.0 then

where x = -1 exactly.  It happens inside a recursive function.

When I have the values of x printed (in bit form: sign, biased exponent,
fractional part), this is what I get:

Computing all choices for optimal Yahtzee strategy ...
OptExpectedScore(123456TFHSLYC;63-): x = 1 01111111111 0000000000000000000000000000000000000000000000000
OptExpectedScore(_23456TFHSLYC;63-): x = 1 01111111111 0000000000000000000000000000000000000000000000000
OptExpectedScore(__3456TFHSLYC;63-): x = 1 01111111111 0000000000000000000000000000000000000000000000000
OptExpectedScore(___456TFHSLYC;63-): x = 1 01111111111 0000000000000000000000000000000000000000000000000
OptExpectedScore(____56TFHSLYC;63-): x = 1 01111111111 0000000000000000000000000000000000000000000000000
OptExpectedScore(_____6TFHSLYC;63-): x = 1 01111111111 0000000000000000000000000000000000000000000000000
OptExpectedScore(______TFHSLYC;33-): x = 1 01111111111 0000000000000000000000000000000000000000000000000
OptExpectedScore(_______FHSLYC;33-): x = 1 01111111111 0000000000000000000000000000000000000000000000000

This means that the if statement is passed 7 times without problem with
x = -1, and on the 8th pass, where x = -1 again, it bails out with an FPE.

How can I get more details about the exception?

What could be causing this?

When I use an ordinary write statement to print the value of x,
it also bombs out on the 8th pass.

Note that x is actually a field in a record stored in a high-dimensional
array that is dynamically allocated, accessed through a with statement.

Using various levels of optimization does not matter.

I am at a loss here,

	Tom
-- 
E-MAIL: T.Verhoeff @ TUE.NL     | Dept. of Math. & Comp. Science
PHONE:  +31 40 247 41 25        | Technische Universiteit Eindhoven
FAX:    +31 40 247 54 04        | PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/  | The Netherlands