Date: Mon, 03 Jan 2000 19:48:14 -0800 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: freebsd-hackers@FreeBSD.ORG Cc: Markus Holmberg <saska@acc.umu.se>, briano@netscape.com, gatgul@voicenet.com, brendan@mozilla.org, waldemar@netscape.com, daeron@Wit401305.student.utwente.nl, clayton@netscape.com, mccabe@netscape.com Subject: Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD? Message-ID: <61309.946957694@monkeys.com> In-Reply-To: Your message of Tue, 04 Jan 2000 02:36:48 %2B0100. <20000104023648.A43673@fysgr387.sn.umu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000104023648.A43673@fysgr387.sn.umu.se>, Markus Holmberg <saska@acc.umu.se> wrote: >IEEE Std 754-1985 (Section 7, paragraph 1) is: > > ``The default response to an exception shall be to proceed > without a trap.'' > >(end quote) > >When checking with a simple C program and fpgetmask() I can confirm that >a couple of bits are set by default, which mean they will trap some >floating point operations. This is consistent with the older postings that >say that default FreeBSD behaviour is *not* conforming with IEEE floating >point standards. > >But when porting software from other platforms this becomes an issue. To >my understanding, doing a fpsetmask(0) makes FreeBSD behave conforming >to IEEE (i.e. not trapping the exceptions). > >Question 1: What is the reason for FreeBSD to differ from other platforms >and not follow the IEEE standard by default? >(Please forgive me if this is an ignorant question.) No, its a Good Question, and I'd like to know the answer also. >To avoid cluttering the code with fpsetmask(0)'s, using a compiler >option to force IEEE conforming fp behaviour would be desirable. This is >where the -mieee-fp parameter for gcc would be handy! No. This would be an entirely inappropriate use of that specific gcc compiler flag. And in fact, *no* special compiler flags should be necessary in order for a compiled C program to conform to the specific IEEE FP rule quoted above. Please understand that gcc compiler flags, and specifically the -mieee-fp option, are meant, in general, to control what type of code gcc emits. That is to say that the gcc compiler options (except those relating to linking, specification of the output file, etc.) For example, there are some machines (I think it is the x86 CPUs, and also the Alphas) where gcc has a choice, and can either generate code for FP operations that is fast or else code that is 100% IEEE conforming. So for those cases, gcc provides the -mieee-fp option... because gcc's default is to just generate fast code, rather than fully IEEE conformant code. But the problem you are talking about has nothing whatsoever to do what what kind of code gcc generates. It only has to do what what the ``pre- main'' code that you programs get linked with (usually called crt0.o) initialize the machine's IEEE trapping flags to. If the existing crt0.o code... which is usually considered sort-of a part of the C library... is failing to initialize all of the IEEE trapping bit to `off', then this just means that someone needs to go in and fix the crt0.o code so that it properly initializes all those bits to off... in order to fully conform to the IEEE 754 FP standard, and specifically to the rule quoted above. >The direct reason for me asking about this is a FreeBSD-specific bug in >Mozilla (that needs help from someone who knows this): > >http://bugzilla.mozilla.org/show_bug.cgi?id=9967 In that Mozilla bugreport, I see the comments: ]------- Additional Comments From brendan@netscape.com 07/15/99 21:32 ------- ]Cc'ing the real IEEE f.p. experts. I too don't want to see this change go in if ]a platform-specific compiler misfeature that results in gratuitous SIGFPEs can ]be disabled via a command line option. My opinion is that brendan is correct, and that littering the Mozilla code with a bunch of hacky kludges all over the place is *NOT* the Right Way to solve such problems. Not at all. The Right Way to solve this problem is for the Mozilla guys to just slip in the statement: fpsetmask(0); right at the very beginning of their main() function. This should be enough to disable the unrequested FP traps on any and all platforms where you/they might possibly get such traps. As I say, the *ideal* way to solve this problem is for every person who maintains a crt0.o file for any given flavor of UNIX to pay a bit more attention to IEEE 754 and for them to arrange to have all FP traps dis- abled already unpon entry into main(). However even if every maintainer of a crt0.o file in the world reads these woards and goes forth and does that TODAY, Mozilla should still be programmed so that it will avoid crashing and burning even when it is compiled on some version of some platform (e.g. FreeBSD) which is already out on the field today. In short, program defensively. You'll never be sorry. -- rfg P.S. It's been a long time now, and I don't remember for sure any more... too many brain cells cooked in my youth I guess... but I seem to recall that I was the guy who talked Stallman into adding the -mieee-fp option. I just mention it so that you will know that... once upon a time at least... I actually *did* know what I was talking about when it came to IEEE FP stuff. 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?61309.946957694>