Re: floating point exceptions

2000-05-05 Thread Martin Cracauer

In [EMAIL PROTECTED], Nate Lawson wrote: 
 I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the
 httperf-0.6 port gives a SIGFPE and dumps core when run against a system
 that has no web server running.  (The default behavior is to measure
 localhost when no arguments are specified). 
 
 It seems this is caused by a divide by zero error since the delta between 
 connections ends up being zero.  The author suggest that the divide 
 should return a defined value, Inf, according to the IEEE floating point 
 standard.  FreeBSD generates SIGFPE.  I temporarily patched the code 
 locally to check for a delta of zero and arbitrarily set it to 1.0 so 
 that the divide succeeds and everything comes out ok without crashing.

FreeBSD up to 3.x defaults to have exceptions unmasked.

This was changed before 4.0 and should be in 4.x/4-STABLE and in
5-current. 

Are you sure you get this on a real 4.0 system, not one from a few
weeks before release?  If so, what is the version of
/usr/include/machine/npx.h?  It should be 1.18.  Of course, the kernel
should be complied with it in case this is a source-updated system.

Anyway, the solution is fpsetmask, as others noted.

Also note that FreeBSD/gcc/ANSI C 89 have a few other problems with
IEEE 754 compatibility so that we can't claim conformity in any case.

Please check the mail archives on www.freebsd.org, this has been
discussed every 7 months for the last 5 years now.

Martin
-- 
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-05-05 Thread Nate Lawson

On Fri, 5 May 2000, Martin Cracauer wrote:
 In [EMAIL PROTECTED], Nate Lawson wrote: 
  I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the
  httperf-0.6 port gives a SIGFPE and dumps core when run against a system
  that has no web server running.  (The default behavior is to measure
  localhost when no arguments are specified). 
  
  It seems this is caused by a divide by zero error since the delta between 
  connections ends up being zero.  The author suggest that the divide 
  should return a defined value, Inf, according to the IEEE floating point 
  standard.  FreeBSD generates SIGFPE.  I temporarily patched the code 
  locally to check for a delta of zero and arbitrarily set it to 1.0 so 
  that the divide succeeds and everything comes out ok without crashing.
 
 FreeBSD up to 3.x defaults to have exceptions unmasked.
 
 This was changed before 4.0 and should be in 4.x/4-STABLE and in
 5-current. 
 
 Are you sure you get this on a real 4.0 system, not one from a few
 weeks before release?  If so, what is the version of
 /usr/include/machine/npx.h?  It should be 1.18.  Of course, the kernel
 should be complied with it in case this is a source-updated system.
 
 Anyway, the solution is fpsetmask, as others noted.
 
 Also note that FreeBSD/gcc/ANSI C 89 have a few other problems with
 IEEE 754 compatibility so that we can't claim conformity in any case.
 
 Please check the mail archives on www.freebsd.org, this has been
 discussed every 7 months for the last 5 years now.

Thanks for the information.  I checked the system again and it is indeed 
4.0-2127-CURRENT (ie. just before 4.0-RELEASE).  I will upgrade.

David, is it possible to add the following to the httperf port?

  #ifdef __FreeBSD__
  fpsetmask(~FP_X_DZ);
  #endif 

Thanks,
Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-27 Thread Andrew Reilly

On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote:
 In the last episode (Apr 26), Sheldon Hearn said:
  On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote:
Is FreeBSD's behavior correct?  Why or why not?  You can use the
included code snippet to verify that this occurs.
   
   FreeBSD has traditionaly violated the IEEE FP standard in this
   regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I
   can't remember what file this is in so I can't check.)
  
  Huh?  I'm pretty sure you've got this backwards.  FreeBSD has
  traditionally upheld the standard and we only recently decided to go
  with the flow in 5.0.
 
 No; we held our moral ground against IEEE, until 5.0 when we gave in. 
 The IEEE standard says "trap nothing".  For most programs, this is the
 wrong thing to do, since they are not signal-processing apps or
 numerical analysis programs and a divide by zero is a coding error. 
 I'd rather have my program die on an unexpected divide by zero than
 continue with invalid data.
 
 Why should we treat (1.0/0.0) any differently from (1/0)?

Because 0.0 might be the closest approximation to whatever
number you were really trying to divide by that the hardware can
manage.  0 is never an approximation to 1 or -1.

Dividing is for wimps, anyway.:-)

-- 
Andrew


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-27 Thread Wes Peters

Wilko Bulte wrote:
 
 On Wed, Apr 26, 2000 at 12:16:51PM -0400, Bill Fumerola wrote:
  On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote:
 
   Why should we treat (1.0/0.0) any differently from (1/0)?
 
  Because Linux has the uncanny ability to both divide by zero and produce
  the shittiest coders the world has ever seen.
 
 Which brings me to the inevitable question: 'can NT divide by zero' ? ;-)

No, at least not in US Navy installations.  It also cannot recover from
divide by zero errors, leading a brand new US warship to be towed in
from sea trials.

The NT-powered nuclear navy.  Be afraid.  Be very afraid.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-26 Thread Sheldon Hearn



On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote:

  Is FreeBSD's behavior correct?  Why or why not?  You can use the included 
  code snippet to verify that this occurs.
 
 FreeBSD has traditionaly violated the IEEE FP standard in this regard.
 This is fixed in 5.0 and I think in 4.0-STABLE (though I can't remember
 what file this is in so I can't check.)

Huh?  I'm pretty sure you've got this backwards.  FreeBSD has
traditionally upheld the standard and we only recently decided to go
with the flow in 5.0.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-26 Thread Dan Nelson

In the last episode (Apr 26), Sheldon Hearn said:
 On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote:
   Is FreeBSD's behavior correct?  Why or why not?  You can use the
   included code snippet to verify that this occurs.
  
  FreeBSD has traditionaly violated the IEEE FP standard in this
  regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I
  can't remember what file this is in so I can't check.)
 
 Huh?  I'm pretty sure you've got this backwards.  FreeBSD has
 traditionally upheld the standard and we only recently decided to go
 with the flow in 5.0.

No; we held our moral ground against IEEE, until 5.0 when we gave in. 
The IEEE standard says "trap nothing".  For most programs, this is the
wrong thing to do, since they are not signal-processing apps or
numerical analysis programs and a divide by zero is a coding error. 
I'd rather have my program die on an unexpected divide by zero than
continue with invalid data.

Why should we treat (1.0/0.0) any differently from (1/0)?

-- 
Dan Nelson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-26 Thread Bill Fumerola

On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote:

 Why should we treat (1.0/0.0) any differently from (1/0)?

Because Linux has the uncanny ability to both divide by zero and produce
the shittiest coders the world has ever seen.

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Office: 800-252-2421 x128 / Cell: 248-761-7272





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-26 Thread Wilko Bulte

On Wed, Apr 26, 2000 at 12:16:51PM -0400, Bill Fumerola wrote:
 On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote:
 
  Why should we treat (1.0/0.0) any differently from (1/0)?
 
 Because Linux has the uncanny ability to both divide by zero and produce
 the shittiest coders the world has ever seen.

Which brings me to the inevitable question: 'can NT divide by zero' ? ;-)

-- 
Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
http://www.tcja.nl


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-26 Thread Dan Nelson

In the last episode (Apr 27), Andrew Reilly said:
 
 Because 0.0 might be the closest approximation to whatever
 number you were really trying to divide by that the hardware can
 manage.  0 is never an approximation to 1 or -1.

Aaah, but that assumes you're not also trapping on underflow :)

-- 
Dan Nelson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-25 Thread Nate Lawson

I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the
httperf-0.6 port gives a SIGFPE and dumps core when run against a system
that has no web server running.  (The default behavior is to measure
localhost when no arguments are specified). 

It seems this is caused by a divide by zero error since the delta between 
connections ends up being zero.  The author suggest that the divide 
should return a defined value, Inf, according to the IEEE floating point 
standard.  FreeBSD generates SIGFPE.  I temporarily patched the code 
locally to check for a delta of zero and arbitrarily set it to 1.0 so 
that the divide succeeds and everything comes out ok without crashing.

Is FreeBSD's behavior correct?  Why or why not?  You can use the included 
code snippet to verify that this occurs.

Thanks,
Nate

-- Forwarded message --
Date: Mon, 24 Apr 2000 15:54:38 -0700 (PDT)
From: David Mosberger [EMAIL PROTECTED]
To: Nate Lawson [EMAIL PROTECTED]
Subject: Re: patch to httperf-0.6

 On Mon, 24 Apr 2000 15:37:21 -0700 (PDT), Nate Lawson [EMAIL PROTECTED] said:

  Nate On x86.  Your code generates SIGFPE, not SIGBUS sorry.  Here
  Nate is a code snippet which generates SIGFPE as well.

  Nate main() { float a, b, c;
  Nate a = 1.0; b = 0.0; c = a/b; }

  Nate This seems to be correct behavior.

No, IEEE says that the exceptions should be disabled by default.  You
should get Inf instead of SIGFPE.

--david



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-25 Thread Brooks Davis

On Mon, Apr 24, 2000 at 11:44:59PM -0700, Nate Lawson wrote:
 I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the
 httperf-0.6 port gives a SIGFPE and dumps core when run against a system
 that has no web server running.  (The default behavior is to measure
 localhost when no arguments are specified). 
 
 It seems this is caused by a divide by zero error since the delta between 
 connections ends up being zero.  The author suggest that the divide 
 should return a defined value, Inf, according to the IEEE floating point 
 standard.  FreeBSD generates SIGFPE.  I temporarily patched the code 
 locally to check for a delta of zero and arbitrarily set it to 1.0 so 
 that the divide succeeds and everything comes out ok without crashing.
 
 Is FreeBSD's behavior correct?  Why or why not?  You can use the included 
 code snippet to verify that this occurs.

FreeBSD has traditionaly violated the IEEE FP standard in this regard.
This is fixed in 5.0 and I think in 4.0-STABLE (though I can't remember
what file this is in so I can't check.)  If upgrading to -stable isn't
an option you can add a call to fpsetmask(3) in the application as
follows (this will work on Solaris and Irix as well):

#include ieeefp.h
...
main() {
declare things

fpsetmask(0);
...
}

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-25 Thread David Mosberger

OK, having to call fpsetmask(0) is an acceptable workaround.  So if I
do:

#ifdef __freebsd___
fpsetmask(0);
#endif

Then this should work on all versions of freebsd?

--david

 On Tue, 25 Apr 2000 00:05:23 -0700, Brooks Davis [EMAIL PROTECTED] 
said:

  Brooks On Mon, Apr 24, 2000 at 11:44:59PM -0700, Nate Lawson wrote:
   I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the
   httperf-0.6 port gives a SIGFPE and dumps core when run against a
   system that has no web server running.  (The default behavior is
   to measure localhost when no arguments are specified).
   
   It seems this is caused by a divide by zero error since the delta
   between connections ends up being zero.  The author suggest that
   the divide should return a defined value, Inf, according to the
   IEEE floating point standard.  FreeBSD generates SIGFPE.  I
   temporarily patched the code locally to check for a delta of zero
   and arbitrarily set it to 1.0 so that the divide succeeds and
   everything comes out ok without crashing.
   
   Is FreeBSD's behavior correct?  Why or why not?  You can use the
   included code snippet to verify that this occurs.

  Brooks FreeBSD has traditionaly violated the IEEE FP standard in
  Brooks this regard.  This is fixed in 5.0 and I think in 4.0-STABLE
  Brooks (though I can't remember what file this is in so I can't
  Brooks check.)  If upgrading to -stable isn't an option you can add
  Brooks a call to fpsetmask(3) in the application as follows (this
  Brooks will work on Solaris and Irix as well):

  Brooks #include ieeefp.h ... main() { declare things

  Brooks   fpsetmask(0); ... }

  Brooks -- Brooks

  Brooks -- Any statement of the form "X is the one, true Y" is
  Brooks FALSE.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: floating point exceptions

2000-04-25 Thread Will Andrews

On Tue, Apr 25, 2000 at 07:47:01AM -0700, David Mosberger wrote:
 OK, having to call fpsetmask(0) is an acceptable workaround.  So if I
 do:
 
 #ifdef __freebsd___
   fpsetmask(0);
 #endif
 
 Then this should work on all versions of freebsd?

#ifdef __FreeBSD__
fpsetmask(0);
#endif

BTW: if you update httperf, let me know so I can update the port (I'm the
maintainer for the httperf port).

-- 
Will Andrews [EMAIL PROTECTED]
GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ 
G+ e- h! r--+++ y?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message