Bug compiling 1.0e-317 floating-point number

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.

Code:

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