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

[David Schultz]

On Sun, Jan 18, 2004, Marcel Moolenaar wrote:
> 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);

I don't think this is strtod's fault.  awk crashes for the same
reason the following program gets a SIGFPE:

	das at pluto1:~> cat bar.c
	int main() {
		double d = 4.0083367200179456e-292;
		d *= 0x1.0p-106;
	}
	
	das at pluto1:~> gcc bar.c
	das at pluto1:~> ./a.out
	Floating exception (core dumped)

The correct result is 4.940656e-324, which is denormalized.  Some
architectures generate a trap for denormals and expect them to be
handled in software, but I didn't think that IA64 was one of them.
I'm looking over the IA64 architecture manual now to see if I can
figure out what's going on...