Date: Thu, 6 Jan 2000 09:36:29 +0100 From: Martin Cracauer <cracauer@cons.org> To: Markus Holmberg <saska@acc.umu.se> Cc: Martin Cracauer <cracauer@cons.org>, freebsd-hackers@freebsd.org Subject: Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD? Message-ID: <20000106093628.A14728@cons.org> In-Reply-To: <20000105205947.A77037@fysgr387.sn.umu.se>; from saska@acc.umu.se on Wed, Jan 05, 2000 at 08:59:47PM %2B0100 References: <20000104121459.A8959@cons.org> <87632.947017515@monkeys.com> <20000105055138.A74746@fysgr387.sn.umu.se> <20000105092356.A8100@cons.org> <20000105205947.A77037@fysgr387.sn.umu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, Folks, first of all I apologize for getting carried away and proposing replacement functions that incompletely implemented the requested behaviour. The equivalent macro with range check is 40% slower (why isn't the MS VC++ specific test case #unifdef'ed for other platforms?). Then, I am not against disabling those exceptions by default that have meaningful results when masked. That are all exceptions that would (if not trapped) result in a floating point value with meaningful semantics: overflow, underflow and divide-by zero. But I am against disabling "invalid operation" by default, because the most often cause of this exception is the case discussed here: A conversion of a too big FP value to an int where it doesn't fit. The result of this operation is at the very least (depending on the C standard in use) an unspecified integer and must not be used. Only in rare cases the programmer knew what he/she did and ignored the result of the operation just carried out. I agree that this Mozilla issue is such a case, the value is supposed to be ignored. But the macro's interface doesn't enforce it. If the macro is that often used in mozilla, I bet I can point out cases where it isn't ignored. Regarding ANSI C: - ANSI C 89 makes it clear that the behaviour is unspecified and that anything may happen and that this macro may not work. An optimizing C89 conforming compiler may chance this code in a way that breaks the macro. - Waldemar is correct that C99 changes the "undefined behaviour" to "the result is an unspecified value". In that case the Mozilla macro is quaranteed to work. However, neither gcc nor FreeBSD claim to be C99 conformant. When thinking about default FP exceptions, it all comes down to the ratio of cases where one exceptions raised a false alarm or where a serious error was caught. In the case of "invalid operation" that ratio is overwhelming in favor of "real" alarms, and in most cases of false alarm (like this Mozilla macro) it points out constructions that need to used with extreme caution. Again: Here we have a programmer that writes a really clever macro that messes with FPU conversions. He knows C89 and C99 enough to point out the relative parts. Code that is so specifically written for one FPU behaviour in mind should set the FPU exception mask. If only to document that it knows what it is doing. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000106093628.A14728>