alpha/36327: trap within cvt() while attempting to
printf() an FP number




>Number: 36327
>Category: alpha
>Synopsis: trap within cvt() while attempting to printf() an FP number
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-alpha
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 26 01:10:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Loren J. Rittle
>Release: 4.2 and 5.0 on alpha hardware
>Organization:
On behalf of libjava project of GCC
>Environment:
FreeBSD clerc-milon.rsch.comm.mot.com 4.2-STABLE FreeBSD 4.2-STABLE #0: Tue Dec
19 09:52:15 CST 2000
rittle@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx:/usr/obj/usr/src/sys/CLERC-MILON alpha
FreeBSD beast.freebsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Sat Mar 16
13:34:04 PST 2002 root@xxxxxxxxxxxxxxxxx:/usr/src/sys/alpha/compile/BEAST
alpha
>Description:
The attached small test case was found by trying to bootstrap libjava
on alpha*-*-freebsd[45]* as will be released with gcc 3.1. The
exact failure in libjava is different than the constructed small test
case but the failure point within the system routine is the same.

Also, I attempted to use the information from fpsetmask(3) to avoid
the trap without success. Even the exact example from the man page
suggested to avoid the divide by zero trap does not work as documented.
>How-To-Repeat:
Compile this program with the system gcc without -O flags on
FreeBSD/alpha:

#include <float.h>
#include <stdio.h>

main() {
double d = DBL_MIN;

printf (" = %.17g;\n", d);
printf ...

(" = %.17g;\n", d/10);
printf (" = %.17g;\n", (DBL_MIN/10)*10);
printf (" = %.17g;\n", (DBL_MIN/10));
}

It will produce this output:

= 2.2250738585072014e-308;
= 0;
= 2.2250738585072034e-308;
floating point exception--core dumped

ISO C might allow the test case to perform as seen. However,
FreeBSD/alpha has a man page discussing how to avoid the trap.
Cut-and-paste the sample code to avoid a divide by zero. It
doesn't disable the trap. It might be OK if there was no way
to avoid the trap with this exact test case but knowing when
it is safe to call libc routines with a given FP value would
be helpful/required to allow libjava to work on FreeBSD/alpha.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-alpha" in the body of the message





Privacy