From nobody  Tue Jun 17 17:28:42 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA18025;
          Tue, 17 Jun 1997 17:28:42 -0700 (PDT)
Message-Id: <199706180028.RAA18025@hub.freebsd.org>
Date: Tue, 17 Jun 1997 17:28:42 -0700 (PDT)
From: ajhar@noao.edu
To: freebsd-gnats-submit@freebsd.org
Subject: False FPE (floating point exception) signaled
X-Send-Pr-Version: www-1.0

>Number:         3895
>Category:       i386
>Synopsis:       False FPE (floating point exception) signaled
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 17 17:30:00 PDT 1997
>Closed-Date:    Tue Apr 14 16:25:04 PDT 1998
>Last-Modified:  Sun May  3 16:00:18 PDT 1998
>Originator:     Edward Ajhar
>Release:        2.2-STABLE (1997 May 29)
>Organization:
National Optical Astronomy Observatories
>Environment:
FreeBSD husa.tuc.noao.edu 2.2-STABLE FreeBSD 2.2-STABLE #0: Wed May 28 13:13:59 MST 1997     ajhar@husa.tuc.noao.edu:/usr/src/sys/compile/HUSA  i386

>Description:
This line causes a false SIGFPE in Fortran code:

     IXY(1) = X + 0.5

where x = 14.  X is a real.

This line of code is executed many, many times before it finally decides
to SIGFPE.

This FPE is signaled with either the optimizer off (on all code) or
on.  The error occurs in exactly the same place in the same way with
f2c (which uses the native FreeBSD gcc-2.7.2.1 compiler) and with
g77-0.5.20 and gcc-2.7.2.2, which I compiled and used separately.
The error occurs with or without gdb.  Everything appears normal before
the SIGFPE.

The same code works when compiled with g77-0.5.20/gcc-2.7.2.2 on an
UltraSparc running Solaris 2.5, which leads me to believe that either there
is a problem with the i386 implementation of gcc-2.7.2 or that there
is something wrong with its implementation on FreeBSD 2.2.

Another false SIGFPE occurs in completely different Fortran code:

           L = UPPER(KEY)

where L is an integer, upper is an integer function, and key is a character.
UPPER returns with the value 88.

The function is successfully called many, many times before it finally decides
to SIGFPE.  The final call is also successful.  The SIGFPE only occurs after
the return of UPPER, when L is to be assigned the value.

This FPE is signaled with either the optimizer off (on all code) or
on.  The error occurs in exactly the same place in the same way with
f2c and with g77-0.5.20/gcc-2.7.2.2.  The error occurs with or without gdb.
Everything appears normal before the SIGFPE.

>How-To-Repeat:
Compile and run my code.  It fails every time.  If I can truly
isolate the problem in a simple program, I will definitely send it along.

See also Problem Report misc/3700, dated Tue May 27 21:20:01 PDT 1997,
from Tim.Brown@ctg.com for a similar problem.

>Fix:

>Release-Note:
>Audit-Trail:

From: Eivind Eklund <eivind@yes.no>
To: freebsd-gnats-submit@freebsd.org, ajhar@noao.edu
Cc:  Subject: Re: i386/3895: False FPE (floating point exception) signaled
Date: Tue, 14 Apr 1998 22:31:05 +0200

 Is this still a problem, and if it is - can you provide us with a
 program that reproduce it?

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.
State-Changed-From-To: open->closed 
State-Changed-By: eivind 
State-Changed-When: Tue Apr 14 16:25:04 PDT 1998 
State-Changed-Why:  
We don't have any reproducable case, and we're not likely to get any. 
The submitter is no longer bothered by the problem. 

From: Craig Wilson <craig@natsoft.com.au>
To: FreeBSD-GNATS-submit@FreeBSD.ORG
Cc:  Subject: Re: i386/3895
Date: Wed, 15 Apr 1998 12:09:56 +0200

 [Forwarded to the GNATS database by Eivind Eklund <eivind@FreeBSD.ORG>]
 
 I have had this problem with the SCO Xenix C compiler.
 It is reproducable with the C compiler in FreeBSD 2.2.2
 It will happen when a routine which returns a float is not
 properly defined in another source file that uses that routine.
 Adding "double getdouble();" prototype in float.c fixes the problem.
 
 float.c
 main()
 {
 	int	i;
 	double	iD;
 	i=0;
 lp:	iD=getdouble();
 	i++;
 	printf("i=%d\n\r",i);
 	goto lp;
 }
 
 float1.c
 double	getdouble()
 {
 	double	iD;
 	iD=1;
 	return iD;
 }
 
 cc float.c float1.c -ofloat
 
 This program will perform 7 loops before crashing with a FPE.
 
 I hope this info helps.
 
 Craig Wilson
 National Software Pty Ltd

From: Tim Vanderhoek <ac199@hwcn.org>
To: Craig Wilson <craig@natsoft.com.au>
Cc: Eivind Eklund <eivind@FreeBSD.ORG>, ajhar@noao.edu,
        bug-followup@FreeBSD.ORG
Subject: Re: i386/3895
Date: Sun, 3 May 1998 01:24:32 -0400 (EDT)

 On Wed, 15 Apr 1998, Craig Wilson wrote:
 
 > > Synopsis: False FPE (floating point exception) signaled
 > > 
 > > State-Changed-From-To: open->closed
 [...]
 > I have had this problem with the SCO Xenix C compiler.
 > It is reproducable with the C compiler in FreeBSD 2.2.2
 > It will happen when a routine which returns a float is not
 > properly defined in another source file that uses that routine.
 
 It happens when it's not properly defined, even if both are in
 the same source file.  It is because when gcc sees getdouble() in
 main, getdouble() defaults to return int.  Unfortunately,
 getdouble() actually returns a double.
 
 This isn't a bug in gcc.  It is arguably a bug in the fortran
 compiler, since, from what I understand, that was what generated
 this code when fed bad code itself.
 
 The PR should remain closed.
 
 
 --
 This .sig is not innovative, witty, or profund.
 

From: Craig Wilson <craig@natsoft.com.au>
To: ac199@hwcn.org
Cc: Eivind Eklund <eivind@FreeBSD.ORG>, ajhar@noao.edu,
        bug-followup@FreeBSD.ORG
Subject: Re: i386/3895
Date: Mon, 04 May 1998 08:59:35 +1000

 Tim Vanderhoek wrote:
 > 
 > On Wed, 15 Apr 1998, Craig Wilson wrote:
 > 
 > > > Synopsis: False FPE (floating point exception) signaled
 > > >
 > > > State-Changed-From-To: open->closed
 > [...]
 > > I have had this problem with the SCO Xenix C compiler.
 > > It is reproducable with the C compiler in FreeBSD 2.2.2
 > > It will happen when a routine which returns a float is not
 > > properly defined in another source file that uses that routine.
 > 
 > It happens when it's not properly defined, even if both are in
 > the same source file.  It is because when gcc sees getdouble() in
 > main, getdouble() defaults to return int.  Unfortunately,
 > getdouble() actually returns a double.
 > 
 > This isn't a bug in gcc.  It is arguably a bug in the fortran
 > compiler, since, from what I understand, that was what generated
 > this code when fed bad code itself.
 > 
 > The PR should remain closed.
 > 
 I agree that it should remain closed.
 I submitted the test C code to inform how the FPE is caused.
 This problem is avoided by the correct use of prototypes etc.
 
 Craig Wilson
 National Software Pty. Ltd.
>Unformatted:
