cvs commit: src/lib/libc/gdtoa Makefile.inc _hdtoa.c src/lib/libc/stdio vfprintf.c

[Marcel Moolenaar]

On Sun, Jan 18, 2004 at 02:33:40AM -0800, David Schultz wrote:
> Any suggestions or bug reports involving this code are welcome, but
> please note the following caveats:
> 
> 	- strtod() has some bugs involving parsing hexadecimal
> 	  floating-point numbers, which should be fixed in the
> 	  next gdtoa import (to come shortly).  Until then, be
> 	  aware that numbers parsed with strtod() may not be
> 	  output as expected because they were not parsed correctly
> 	  in the first place.  In particular, don't specify too
> 	  many digits in the significand for subnormals, and
> 	  don't expect underflow to zero to work correctly.

Currently stdtod() is causing a SIGFPE on ia64 for a kernel build.
This started when obrien@ added the following code to kern.post.mk:

+emu10k1-alsa%diked.h: $S/gnu/dev/sound/pci/emu10k1-alsa.h
+       grep -v '#include' ${.OODATE} | ${CC} -E -D__KERNEL__ -dM - \
+           | awk -F"[  (]" '/define/ \
+           { print "#ifndef " $$2 ; print ; print "#endif" }' \
+           >${.TARGET}
+.if !exists(${.OBJDIR}/.depend)
+_kernel-depend: emu10k1-alsa%diked.h
+.endif
                                                                                
The problem is that awk(1) gets a SIGFPE unconditionally. I haven't
spent too much time on it yet, but I get the following in the gdb(1):
 
Program received signal SIGFPE, Arithmetic exception.
0x40000000000553d2 in strtod (s00=0x600000000001c02d "e-324",
    se=0x9fffffffffffe6f0) at gdtoa_strtod.c:938
938                     dval(rv) *= dval(rv0);
(gdb)

0x40000000000553d0 <strtod+16224>:      [MFB]       nop.m 0x0
0x40000000000553d1 <strtod+16225>:                  fmpy.d.s0 f6=f7,f6
0x40000000000553d2 <strtod+16226>:                  nop.b 0x0;;

(gdb) info reg f6 f7
f6             8.8817841970012523233890533447265625e-16 (raw 0x000000000000fbcd8000000000000000)
f7             4.0083367200179455559922161027003241e-292        (raw 0x000000000000fc378000000000000000)
(gdb) Erroneous arithmetic operation.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Very suspicious gdb(1) error. Don't trust the register values.

If you're interested in analyzing this, I have the above trigger case
in ~marcel/strtod on @FreeBSD.org. The awk(1) executable in that
directory has full debugging information (including libc). Run as:

./awk -F"[  (]" '/define/ { print "#ifndef " $2 ; print ; print "#endif" }' < awk.in

FYI,

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net