From owner-freebsd-current Fri Oct 3 12:11:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA06311 for current-outgoing; Fri, 3 Oct 1997 12:11:48 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA06287; Fri, 3 Oct 1997 12:11:33 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id FAA28989; Sat, 4 Oct 1997 05:05:45 +1000 Date: Sat, 4 Oct 1997 05:05:45 +1000 From: Bruce Evans Message-Id: <199710031905.FAA28989@godzilla.zeta.org.au> To: cracauer@cons.org, jkh@time.cdrom.com Subject: Re: xlock: caught signal 8 while running galaxy mode. Cc: freebsd-current@FreeBSD.ORG, Matthew.Thyer@dsto.defence.gov.au, ports@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I tried to convince people that FreeBSD hurts itself here, and the >> dying screensavers are my primary example how this can hurt users. The Dying screensavers are a good example of why trapping on FP exceptions is good: FP exceptions are often due to bugs, and trapping helps find the bugs. Galaxy mode gets a SIGFPE for an overflowing float to int conversion near line 363 in galaxy.c: --- #ifndef NO_VELOCITY_COLORING st->color = COLORSTEP * gt->galcol + ((int) ((v0 * v0 + v1 * v1 + v2 * v2) / (3.0 * DELTAT * DELTAT))) % COLORSTEP; #endif --- If (v0 * v0 + v1 * v1 + v2 * v2) is greater than or equal to INT_MAX + 1.0, then casting it to int gives undefined behaviour. The actual behaviour on i386's (if FP exceptions are not trapped) is to give the result INT_MIN. Note that this has the wrong sign as well as being too small. This happens to be unimportant here. >> solution was to tell the port maintainers to switch FP mode for their >> ports, which haven't happend for any port, as far as I know. According to "find /home/ncvs/ports -name 'patch-*' | xargs grep fpsetmask", fpsetmask() is used in the following ports: Scilab, felt, mpeg2codec, vfghostscript and has been used in the following ports: tcl, tcl74. >> There are bugs in our gcc that make relying on FP exceptions handled >> right dangerous and Bruce Evans felt it is better to through the >> signal, so that people get aware of the problem. I don't know of any bugs in gcc related to FP exceptions. >> With all respect to Bruce, I'm still conviced that we should switch to >> default to set exceptional values and not signal the process. Our gcc >> isn't that much worse than NetBSD's and Linux and those systems >> obviously didn't get into trouble, at least not my my applications. How is our gcc worse than NetBSD's or Linux's? >You're not alone in this point of view, but even several of us arguing >for years with Bruce on this issue has not been enough to sway him >from the point of view that purity exceeds the value of functionality >here. :-) Who is Bruce? ;-) bde's point of view is recorded in npx.h: --- /* Intel prefers long real (53 bit) precision */ #define __iBCS_NPXCW__ 0x262 /* wfj prefers temporary real (64 bit) precision */ #define __386BSD_NPXCW__ 0x362 /* * bde prefers 53 bit precision and all exceptions masked. --- This hasn't changed since 386BSD-0.1. I decided not to commit the change to the control word until someone fixes the error handling in lib/msun. Bruce