From: <ams AT ludd DOT luth DOT se>
Message-Id: <200303221153.h2MBriK22198@speedy.ludd.luth.se>
Subject: t-strtof discrepancies
To: DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Date: Sat, 22 Mar 2003 12:53:44 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-MailScanner: Found to be clean
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Running t-strtof (as in my patch of today) on a 386 (no FPU) and an
Athlon (with FPU, most likely representative for all 486DX or better)
gives the following differences:

--- == 386
+++ == Athlon

--- /x2/doze_scratch/STRTOF_S.TXT       Sat Mar 22 12:09:52 2003
+++ /x2/doze_scratch/strtof_winsartre.txt       Sat Mar 22 12:07:34 2003
@@ -10,9 +10,9 @@
 Test 9: 0.002 -> 0.002
 Test 10: 2e-37 -> 2e-37
 Test 11: 2e-38 -> 2e-38
-Test 12: 6.87747e-39 -> 6.87747e-39
-Test 13: 5.87748e-39 -> 5.87748e-39
-Test 14: 5.87747e-39 -> 8.81621e-39
+Test 12: 2e-39 -> 2e-39
+Test 13: 9.80909e-45 -> 9.80909e-45
+Test 14: 1.4013e-45 -> 1.4013e-45
 float_t tests:
 Test 1: Inf -> Inf
 Test 2: NaN -> NaN
@@ -23,8 +23,8 @@
 strtof(sprintf(..., -FLT_MAX * 10)) == -HUGE_VALF: Yes - OK
 strtof(sprintf(..., DBL_MAX)) == HUGE_VALF: Yes - OK
 strtof(sprintf(..., -DBL_MAX)) == -HUGE_VALF: Yes - OK
-strtof(sprintf(..., LDBL_MAX)) == HUGE_VALF: No - FAIL
-strtof(sprintf(..., -LDBL_MAX)) == -HUGE_VALF: No - FAIL
+strtof(sprintf(..., LDBL_MAX)) == HUGE_VALF: Yes - OK
+strtof(sprintf(..., -LDBL_MAX)) == -HUGE_VALF: Yes - OK
 Infinity tests:
 strtof("inF", &endptr) -> Inf, 3 - OK
 strtof("-INf", &endptr) -> -Inf, 4 - OK
@@ -50,8 +50,8 @@
 strtof("-nan(0)", &endptr) -> NaN, 7 - OK
 strtof("nan(0x401234)", &endptr) -> NaN, 13 - OK
 strtof("-nan(0x400088)", &endptr) -> NaN, 14 - OK
-strtof("nan(0x1234)", &endptr) -> NaN, 11 - OK
-strtof("-nan(0x88)", &endptr) -> NaN, 10 - OK
+strtof("nan(0x1234)", &endptr) -> NaN, 11 - mantissa == 0x401234 != 0x1234 - FAIL
+strtof("-nan(0x88)", &endptr) -> NaN, 10 - mantissa == 0x400088 != 0x88 - FAIL
 strtof("-nan(0xaa7d7aa74)", &endptr) -> NaN, 17 - OK
 strtof("nan(0x12345678123456781)", &endptr) -> NaN, 24 - OK
 strtof("-nan(0x12345678123456781)", &endptr) -> NaN, 25 - OK

1. Tests 12, 13, 14 don't look like failures, but the numbers are
different! Is it broken or not? Or is it sprintf() that is broken?

2. LDBL_MAX tests breaks on emulation.

3. SNaN is not converted into QNaN. Sort of expected if you think
about it.


So I set out to debug this. Alas the usual problem (mentioned by me a
year or so ago) with debugging code with floating point emulation
appears:

ebp=00092adc esp=00092adc program=F:\DJGPP\TESTS\LIBC\C99\STDLIB\M
cs: sel=00e7  base=10270000  limit=000affff
ds: sel=00ef  base=10270000  limit=000affff
es: sel=00ef  base=10270000  limit=000affff
fs: sel=00df  base=000473a0  limit=00003fff
gs: sel=00ff  base=00000000  limit=0010ffff
ss: sel=00ef  base=10270000  limit=000affff
App stack: [00092db4..00012db4]  Exceptn stack: [00012d48..00010e08]
 
Call frame traceback EIPs:
  0x00095895 0x95895
  0x0009a8a7 0x9a8a7
  0x0009b25f 0x9b25f
  0x000030a6 _fde_split+234
  0x00005356 _raise+110
  0x000053b7 ___djgpp_exception_processor+35
  0x00000001 0x1
  0x00001c67 _main+155, line 137 of t-strtof.c
  0x000038ac ___crt1_startup+204
 
Program exited with code 0377.
(gdb) q
 
F:\DJGPP\TESTS\LIBC\C99\STDLIB>symify -o k:m.txt m

Usually doing "handle SIGEMT nostop" and "handle SIGFPE nostop" (IIRC)
worked around this, but this time it won't. Perhaps because this time
I'm trying to step through FPU instructions.

Note that I haven't tried a clean 2.03 libc etc. I'm using CVS plus
Charles' DXE patch from a long time ago.

gdb version is 5.0.

I'm willing to try things if somebody wants to. Either for the
debugging problem or 1 or 2 above.


Right,

						MartinS