Date: Tue, 14 Apr 1998 14:30:01 -0700 (PDT) From: Edward Ajhar <ajhar@noao.edu> To: freebsd-bugs Subject: Re: i386/3895: False FPE (floating point exception) signaled Message-ID: <199804142130.OAA17494@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/3895; it has been noted by GNATS. From: Edward Ajhar <ajhar@noao.edu> To: freebsd-gnats-submit@freebsd.org, eivind@yes.no Cc: Subject: Re: i386/3895: False FPE (floating point exception) signaled Date: Tue, 14 Apr 1998 14:25:09 -0700 (MST) Thanks for prodding me, I kept forgetting to submit a follow-up. While I am not _certain_ that this problem still exists (I suspect it does), I have found a way around it. There were two examples of problems given in the original i386/3895. Here is the first. Actually, the origin of the problem is in the Fortran code that I was running. With the caveat that the following is in part speculative, here is the main clue to what is probably a gcc bug: The (Fortran) code had a bad habit of CALLing FUNCTIONs (which return values) instead of assigning them to a dummy variable. In Fortran, only SUBROUTINEs (which do not return values) are CALLed, but most compilers don't seem to care if you also use CALL for a function. Anyway, the returned value was, perhaps, left on the stack. As these unused values piled up, they could ultimately trigger a false SIGFPE. I really don't know exactly what caused the problem, but fixing the Fortran code (by assigning functions to dummy variables instead of calling them) removed this problem. The second example was an assignment of an integer function to an integer and having it give a false SIGFPE. It turns out that this function when defined was an INTEGER but was implicitly declared a REAL when it was called in the code (because of Fortran's implicit rules). Again, the compilers were perfectly happy to swallow all this, and the code was happy to run on the (Solaris) UltraSparc with the same code (without any problem) and to run happily for a while on the (FreeBSD) Pentium Pro machine. But, eventually, a false SIGFPE resulted. All this led me to conclude that there is probably a bug somewhere in the i386 gcc code because the results were the same whether using f2c (which converts the Fortran code into C, which is then compiled directly with gcc as C code) or g77 (which is the Fortran front-end of gcc). But, unfortunately, I cannot provide a simple little piece of C code that reproduces this bug. So, I suppose that this one probably has to be left hanging for now. In my humble opinion, because improperly written Fortran code somehow found a way to trigger a (likely) gcc bug and because fixing the Fortran code apparently fails to trigger the bug, this seems to be a _much_ lower priority problem and probably something well beyond the scope of the FreeBSD Project to try to locate and fix at this time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804142130.OAA17494>