There is a FASM bug (v 1.71.20) when compiling the number 1.0e-317. In the example below, FASM compiles the number as 4.294967e-308. These are tiny denormal numbers, so the values aren't exactly what the human eye would expect, but this is clearly a bug.
The code below loads each number into the FPU, so that you can step through the code to see how the FPU interprets it.
format PE GUI 4.0
entry start
include 'win32w.inc'
section '.text' code readable executable
start:
; Loop through values...
mov ecx, Nums.len
mov esi, Nums
@@:
fld qword [esi] ; Load number to look at
fstp st0 ; Pop off FPU stack
add esi, 8 ; Next Num...
dec ecx
jnz @b
invoke ExitProcess, -1
section '.data' data readable writeable
align 8
label Nums qword
dq 1.0e-318
dq 1.0e-317 ; FASM thinks this is 4.294967e-308!!!!
dq 1.0e-316
dq 1.0e-315
.len = ($-Nums)/8
section '.idata' import data readable writeable
library kernel32,'KERNEL32.DLL',\
user32,'USER32.DLL'
include 'api\kernel32.inc'
include 'api\user32.inc'
I've suspected this corruption before in previous versions when compiling floating-point numbers, and now I've finally nailed it with some easy-to-reproduce code.
Please fix this!!
ejamesr