Date: Sat, 4 Oct 1997 05:05:45 +1000 From: Bruce Evans <bde@zeta.org.au> To: cracauer@cons.org, jkh@time.cdrom.com Cc: freebsd-current@FreeBSD.ORG, Matthew.Thyer@dsto.defence.gov.au, ports@FreeBSD.ORG Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199710031905.FAA28989@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710031905.FAA28989>