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:
(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.