From owner-freebsd-bugs  Tue Apr 14 14:30:02 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA17508
          for freebsd-bugs-outgoing; Tue, 14 Apr 1998 14:30:02 -0700 (PDT)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA17494;
          Tue, 14 Apr 1998 14:30:01 -0700 (PDT)
          (envelope-from gnats)
Date: Tue, 14 Apr 1998 14:30:01 -0700 (PDT)
Message-Id: <199804142130.OAA17494@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Edward Ajhar <ajhar@noao.edu>
Subject: Re: i386/3895: False FPE (floating point exception) signaled
Reply-To: Edward Ajhar <ajhar@noao.edu>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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