Bug 36327

I beleive this only works for floating point operations which have
software completion enabled.  Eg, -mieee.

Have you tried adding  -mieee to CFLAGS?

Drew


Loren J. Rittle writes:
 > 
 > >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@clerc-milon.rsch.comm.mot.com:/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@beast.freebsd.org:/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@FreeBSD.org
 > with "unsubscribe freebsd-alpha" in the body of the message

> I beleive this only works for floating point operations which have
> software completion enabled.  Eg, -mieee.

OK.

> Have you tried adding  -mieee to CFLAGS?

Yes, I see that I failed to report it, but I did try the test case
with -mieee and without it.  As far as I can see, the mechanism
documented to disable underflow traps is not working on
alpha*-*-freebsd4.2 or alpha*-*-freebsd5.0 OR there is a bug in the
handling of some FP numbers in cvt() which causes a non-maskable FP
trap.  Sorry I should have posted a complete example.  Here is one
that fails:

; cat tq.c 
#include <float.h>
#include <stdio.h>
#include <ieeefp.h>

main() {
  double d = DBL_MIN;

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

; /usr/bin/gcc -mieee tq.c
; a.out
 = 2.2250738585072014e-308;
floating point exception--core dumped

Exact same output when compiled without -mieee.

In any event, it is not the code for d/10 that traps.  It is code
inside cvt() which is called from vfprintf().  Two issues: Should a
library routine ever internally trap; no matter what the mask setting?
Shouldn't there be some way to disable the trap?

Regards,
Loren

Comment 3 David Schultz 2004-05-05 11:05:34 UTC

This problem seems to have gone away, perhaps due to the import of
a recent version of the dtoa routines.  Can you confirm that it's
no longer an issue?

In article <20040505100534.GA51426@VARK.homeunix.com>,
David Schultz<das@FreeBSD.ORG> writes:

> This problem seems to have gone away, perhaps due to the import of
> a recent version of the dtoa routines.  Can you confirm that it's
> no longer an issue?

Confirm that it is gone in -CURRENT.

Comment 5 David Schultz 2004-05-10 19:58:10 UTC

State Changed
From-To: open->closed

Submitter confirms that problem no longer occurs in -CURRENT.