From nobody@FreeBSD.org  Tue Mar 26 01:06:03 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id D34DC37B417
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 26 Mar 2002 01:06:02 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g2Q962l84742;
	Tue, 26 Mar 2002 01:06:02 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200203260906.g2Q962l84742@freefall.freebsd.org>
Date: Tue, 26 Mar 2002 01:06:02 -0800 (PST)
From: "Loren J. Rittle" <ljrittle@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: trap within cvt() while attempting to printf() an FP number
X-Send-Pr-Version: www-1.0

>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:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 26 01:10:00 PST 2002
>Closed-Date:    Mon May 10 11:58:36 PDT 2004
>Last-Modified:  Mon May 10 11:58:36 PDT 2004
>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:

From: Andrew Gallatin <gallatin@cs.duke.edu>
To: "Loren J. Rittle" <ljrittle@FreeBSD.ORG>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: alpha/36327: trap within cvt() while attempting to printf() an FP number
Date: Tue, 26 Mar 2002 09:21:25 -0500 (EST)

 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

From: Loren James Rittle <rittle@latour.rsch.comm.mot.com>
To: gallatin@cs.duke.edu
Cc: ljrittle@freebsd.org, freebsd-gnats-submit@freebsd.org
Subject: Re: alpha/36327: trap within cvt() while attempting to printf() an FP number
Date: Tue, 2 Apr 2002 02:13:21 -0600 (CST)

 > 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

From: David Schultz <das@FreeBSD.ORG>
To: freebsd-gnats-submit@FreeBSD.ORG, ljrittle@FreeBSD.ORG
Cc:  
Subject: Re: alpha/36327: trap within cvt() while attempting to printf() an FP number
Date: Wed, 5 May 2004 03:05:34 -0700

 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?

From: Loren James Rittle <rittle@latour.rsch.comm.mot.com>
To: das@FreeBSD.ORG
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: alpha/36327: trap within cvt() while attempting to printf() an FP number
Date: Mon, 10 May 2004 13:45:52 -0500 (CDT)

 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.
State-Changed-From-To: open->closed 
State-Changed-By: das 
State-Changed-When: Mon May 10 11:58:10 PDT 2004 
State-Changed-Why:  
Submitter confirms that problem no longer occurs in -CURRENT. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=36327 
>Unformatted:
