NetBSD Problem Report #6634

Received: (qmail 11212 invoked from network); 22 Dec 1998 14:33:58 -0000
Message-Id: <199812221432.HAA10778@polaris.garbled.net>
Date: Tue, 22 Dec 1998 07:32:09 -0700 (MST)
From: Tim Rightnour <root@polaris.garbled.net>
Reply-To: root@polaris.garbled.net
To: gnats-bugs@gnats.netbsd.org
Subject: divide by zero gives strange results on alpha
X-Send-Pr-Version: 3.95

>Number:         6634
>Category:       port-alpha
>Synopsis:       divide by zero gives strange results on alpha
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    ross
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 22 07:05:04 +0000 1998
>Closed-Date:    Tue Mar 24 21:55:45 +0000 2009
>Last-Modified:  Tue Mar 24 22:00:03 +0000 2009
>Originator:     Tim Rightnour
>Release:        1.3.2
>Organization:
Tim Rightnour  -  root@garbled.net
Free Multi-Platform Operating System: http://www.netbsd.org
NetBSD Mailing lists on the web: http://mail-index.netbsd.org/mlist
>Environment:

System: NetBSD polaris 1.3.2 NetBSD 1.3.2 (POLARIS) #1: Fri Nov 6 07:41:34 MST 1998 root@:/usr/src/sys/arch/i386/compile/POLARIS i386


>Description:
Ran a test program on i386 and alpha, to divide by zero, and spit out the
results, hoping to find out why perl dumps core when dividing by zero on
alpha, and found:

(i386)
[/home/garbled] polaris# ./float
i: Inf
j: Inf

(alpha)
giauzar# ./float 
i: Inf
j: 340282346638528859811704183484516925440.000000


>How-To-Repeat:
#include <stdio.h>

main() {

double i;
float j;

i = 12.0 / 0;
printf("i: %f\n", i);
j = 12.0 / 0;
printf("j: %f\n", j);

}

>Fix:
Not sure.. is this even a bug?  Is "Inf" being promoted incorrectly?

>Release-Note:
>Audit-Trail:

From: Todd Vierling <tv@pobox.com>
To: Tim Rightnour <root@polaris.garbled.net>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/6634: divide by zero gives strange results on alpha
Date: Tue, 22 Dec 1998 16:06:47 -0500 (EST)

 On Tue, 22 Dec 1998, Tim Rightnour wrote:

 : double i;
 : float j;
 : 
 : i = 12.0 / 0;
 : printf("i: %f\n", i);
 : j = 12.0 / 0;
 : printf("j: %f\n", j);

 This is not legal ANSI C, and "gcc -Wformat" should tell you about it.

 The argument of %f is a double, not a float - what you end up with is a
 double containing the bits of j and a float-sized array of random bits off
 the stack.

 The correct last statement should read:

 printf("j: %f\n", (double)j);

 -- 
 -- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)


From: Todd Vierling <tv@pobox.com>
To: Tim Rightnour <root@polaris.garbled.net>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/6634: divide by zero gives strange results on alpha
Date: Tue, 22 Dec 1998 16:09:48 -0500 (EST)

 On Tue, 22 Dec 1998, Tim Rightnour wrote:

 : j: 340282346638528859811704183484516925440.000000

 Of course, I sprake too soon, and it turns out that even the cast does not
 work.  Yum!

 Yes, in that case, it's certainly a bug.

 -- 
 -- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)


From: Kevin Schoedel <schoedel@kw.igs.net>
To: Todd Vierling <tv@pobox.com>
Cc: Tim Rightnour <root@polaris.garbled.net>, gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/6634: divide by zero gives strange results on alpha
Date: Tue, 22 Dec 98 17:21 EST

 >The argument of %f is a double, not a float - what you end up with is a
 >double containing the bits of j and a float-sized array of random bits off
 >the stack.
 >
 >The correct last statement should read:
 >
 >printf("j: %f\n", (double)j);

 Actually,

 	printf("j: %f\n", j);

 is OK.

 Assuming this fails for normal floats (i.e. where division by zero
 is not involved, *or* if the compiler claims to handle that division by
 producing a printable float infinity), and assuming that printf() is
 properly declared (as including <stdio.h> in the original PR presumably
 did), then there *is* a bug: the compiler should be promoting the float
 to double when passing it to printf().

 I went through this recently with gcc or egcs (can't remember) with a
 different processor (PowerPC) and different type (char), so this might be
 a pervasive gcc and/or egcs bug. (It worked on i386 in that case too.)

 For reference, the relevant parts of section 6.3.2.2 of the standard:

 	.... integral promotions are performed on each argument and
 	arguments that have type float are converted to double. These
 	are called the *default argument promotions*.... The ellipsis
 	notation in a function prototype declarator causes argument
 	type conversion to stop after the last declared parameter.
 	The default argument promotions are performed on trailing arguments.

 -- 
 Kevin Schoedel
 schoedel@kw.igs.net

From: Ross Harvey <ross@teraflop.com>
To: schoedel@kw.igs.net, tv@pobox.com
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org,
        root@polaris.garbled.net
Subject: Re: port-alpha/6634: divide by zero gives strange results on alpha
Date: Tue, 22 Dec 1998 16:26:27 -0800 (PST)

 > Actually,
 >
 > 	printf("j: %f\n", j);
 >
 > is OK.
 >

 Agreed. From day one, floats were promoted to double. ANSI adds new rules on top
 of the old ones, but the stdarg case effectively disables them.

   --Ross Harvey
Responsible-Changed-From-To: gnats-admin->port-alpha-maintainer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Mon Dec 28 09:33:08 PST 1998 
Responsible-Changed-Why:  
This PR is the responsibility of the portmaster, 
not the GNATS database administrator. 

From: Ross Harvey <ross@ghs.com>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: port-alpha/6634: divide by zero gives strange results on alpha
Date: Mon, 30 Apr 2001 18:41:41 -0700 (PDT)

 Ok, a few comments.

 The reason divide-by-zero cores in perl is because this is the default
 alpha architecture behavior on all alpha kernels, and apparently perl
 was built with the default cc(1) arguments.

 Had you built perl with -mieee, then it still would have cored, because
 until recently we didn't have kernel support for that. On cray's and vaxes,
 divide by zero always generates SIGFPE, so i would be careful about using
 the x86 as the gold standard. But if you like, now in -current you can
 build perl with -mieee and then you should get the pc behavior.

 On this program, a couple of strange things happen. For one thing, by giving
 the whole expression to gcc in constants, gcc collapses the constants and
 you never really find out what a run-time div-by-zero would have done.

 When I'm writing tests like this, I put the divide in a function that takes
 the divsor as a parameter. I then declare a global for use as the divisor,
 and pass it to the function from main. This way, gcc can't possibly know
 if it was intialized or modified from another module, and it is forced to
 really do the divide.

 It gets stranger, tho. Gcc only assembles a single constant when the program
 is compiled with -mieee, and this does turn into an infinity in both the
 single and double case. Without -mieee, it looks like it gives you a
 real infinity for the double, but FLT_MAX for the single. Go figure.

 Now, I don't know what to do with this PR. The inconsistent behavior
 seems a little odd. I'll check 754 to see if Inf is defined for float.

 	--ross
State-Changed-From-To: open->analyzed 
State-Changed-By: thorpej 
State-Changed-When: Fri May 4 10:24:52 PDT 2001 
State-Changed-Why:  
Ross has partially analyzed this problem, and has added FP completion 
to -current. 


Responsible-Changed-From-To: port-alpha-maintainer->ross 
Responsible-Changed-By: thorpej 
Responsible-Changed-When: Fri May 4 10:24:52 PDT 2001 
Responsible-Changed-Why:  
Ross is responsible for FP goo. 

From: "R.o.s.s  H.a.r.v.e.y" <ross@ghs.com>
To: gnats-bugs@gnats.netbsd.org
Cc: garbled@netbsd.org, thorpej@wasabisystems.com
Subject: Re: port-alpha/6634: divide by zero gives strange results on alpha
Date: Fri, 18 Jan 2002 16:47:46 -0800 (PST)

 This is totally a compiler problem.

 To fix the gcc bug:

 	gcc should not evaluate that expression at compile time,
 	because it doesn't know if the divide-by-zero exception
 	will be enabled at runtime. (Furthermore, _some_ floating ops
 	are supposed to *produce different results* if the trap is
 	enabled or not. Mmm, ieee. Divide is not one of those,
 	tho.)

 	Solution: don't collapse floating expressions, or at least
 	don't collapse ones that signal one of the 5 ieee conditions.

 	If this is done, then the fact that it produces Inf for
 	double and FLT_MAX for single ceases to matter.

 	OTOH, if it wants to just assume that the program is in
 	the default nontrapping mode (ieee default, actually, the
 	AARM specified alpha default is non-ieee, sigh) then I
 	suppose that's OK with me, I don't care so much about 754
 	compliance, but IN THAT CASE it should return an infinity
 	for both the single and the double case.  An infinity has
 	an exponent of all ones (2047 or 255) and a fraction
 	of 0.  (Note: sign matters. There is both +- infinity.)


 It's possible that the cc(1) compiler driver should automatically
 be adding -mieee.  I think this violates the AARM which at least
 implies that the compiler default will be the "alpha default" of
 no software completion. It's also kind of (personally :-) annoying
 to contemplate this.

 However, there are a couple of good reasons.

 1. Correct me if I'm wrong, but we don't have any general way to
 force compiler options on pkgsrc builds, right?  I mean, we are at
 the mercy of the package's own Makefile for running cc. So the ONLY
 way to build packages with -mieee is to fix the driver. Perhaps it
 should take an environment variable.

 Building all pkgs with -mieee would be helpful, as it would make
 them run more like on i386, and we wouldn't bomb out just because
 a pkg thinks it can divide by zero casually. (Search for "stupid
 divide" in www.netbsd.org/People/Pages/ross-essays.html#ieee-754)

 2. The degree to which alpha subsets IEEE depends highly on the
 chip itself. Consequently, we won't necessarily provide the same
 functionality between alpha models if we don't do -mieee, sigh.
 This is sort of related to the "behave like x86" argument.  (Ahh,
 we still won't be the same on all alphas or the same as x86 unless
 we also do -mieee-with-inexact, but that is way too expensive on
 older chips.)

 	r.o.s.s

From: Tim Rightnour <root@garbled.net>
To: "R.o.s.s  H.a.r.v.e.y" <ross@ghs.com>
Cc: thorpej@wasabisystems.com, gnats-bugs@gnats.netbsd.org
Subject: Re: port-alpha/6634: divide by zero gives strange results on alp
Date: Fri, 18 Jan 2002 23:25:34 -0700 (MST)

 On 19-Jan-02 R.o.s.s  H.a.r.v.e.y wrote:
 > 1. Correct me if I'm wrong, but we don't have any general way to
 > force compiler options on pkgsrc builds, right?  I mean, we are at
 > the mercy of the package's own Makefile for running cc. So the ONLY
 > way to build packages with -mieee is to fix the driver. Perhaps it
 > should take an environment variable.
 > 
 > Building all pkgs with -mieee would be helpful, as it would make
 > them run more like on i386, and we wouldn't bomb out just because
 > a pkg thinks it can divide by zero casually. (Search for "stupid
 > divide" in www.netbsd.org/People/Pages/ross-essays.html#ieee-754)

 So.. Honestly it's been so long since I filed this PR I kinda forget the root
 of the problem.. But to answer your question, yes, you are sorta wrong.

 Can You force a specific pkg to use compiler flag N on a specific arch?  
 yes, farily trivially.

 Can you force all pkgs to use a compiler flag N on a specific arch?
 No, but you can ask nicely, and *most* pkgs will obey.

 Basically.. on alot of pkgs, you can set CFLAGS in the top level Makefile, and
 for those makefiles that don't do "CFLAGS=" it will be a-ok.  Generally
 speaking, the ones that use gnu configure seem to do the best.

 ---
 Tim Rightnour <root@garbled.net>
 NetBSD: Free multi-architecture OS http://www.netbsd.org/
 NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi
State-Changed-From-To: analyzed->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 03 May 2008 02:22:37 +0000
State-Changed-Why:
Has gcc4 helped this at all?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 26 Oct 2008 21:39:40 +0000
State-Changed-Why:
Feedback timeout. Anyone with an alpha want to test the current state of
things?


From: David Huang <khym@azeotrope.org>
To: gnats-bugs@NetBSD.org
Cc: netbsd-bugs@netbsd.org,
 dholland@NetBSD.org
Subject: Re: port-alpha/6634 (divide by zero gives strange results on alpha)
Date: Mon, 27 Oct 2008 00:34:18 -0500

 On Oct 26, 2008, at 4:39 PM, dholland@NetBSD.org wrote:

 > Synopsis: divide by zero gives strange results on alpha
 >
 > State-Changed-From-To: feedback->open
 > State-Changed-By: dholland@NetBSD.org
 > State-Changed-When: Sun, 26 Oct 2008 21:39:40 +0000
 > State-Changed-Why:
 > Feedback timeout. Anyone with an alpha want to test the current  
 > state of
 > things?

 yerfable /tmp> uname -a
 NetBSD yerfable.azeotrope.org 4.99.72 NetBSD 4.99.72 (YERFABLE) #0:  
 Sat Sep 27 21:42:24 CDT 2008  khym@cheetah.azeotrope.org:/usr/ 
 obj.alpha/sys/arch/alpha/compile/YERFABLE alpha
 yerfable /tmp> cc -v
 Using built-in specs.
 Target: alpha--netbsd
 Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure -- 
 enable-long-long --disable-multilib --enable-threads --disable-symvers  
 --build=x86_64-unknown-netbsd4.99.72 --host=alpha--netbsd -- 
 target=alpha--netbsd --enable-__cxa_atexit
 Thread model: posix
 gcc version 4.1.3 20080704 prerelease (NetBSD nb1 20080202)
 yerfable /tmp> cc -o float float.c
 float.c: In function 'main':
 float.c:8: warning: division by zero
 float.c:10: warning: division by zero
 .yerfable /tmp> ./float
 Floating exception (core dumped)
 yerfable /tmp> cc -o float -mieee float.c
 float.c: In function 'main':
 float.c:8: warning: division by zero
 float.c:10: warning: division by zero
 yerfable /tmp> ./float
 i: inf
 j: inf

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Tue, 24 Mar 2009 21:55:45 +0000
State-Changed-Why:
Fixed by gcc4.


From: David Holland <dholland-bugs@netbsd.org>
To: David Huang <khym@azeotrope.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/6634 (divide by zero gives strange results on alpha)
Date: Tue, 24 Mar 2009 21:55:04 +0000

 On Mon, Oct 27, 2008 at 12:34:18AM -0500, David Huang wrote:
 >> Feedback timeout. Anyone with an alpha want to test the current state 
 >> of things?
 >
 > yerfable /tmp> uname -a
 > [...]
 > yerfable /tmp> ./float
 > i: inf
 > j: inf

 Looks as if the compiler part of the problem is fixed. Thanks for
 testing...

 Since it doesn't appear that forcing -mieee everywhere is a
 particularly good idea (and, realistically, anything that wants to
 divide by zero freely needs a SIGFPE handler) I think we can close the
 PR.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.