Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!natinst!bigtex!james
From: james@bigtex.cactus.org (James Van Artsdalen)
Newsgroups: comp.unix.sysv386
Subject: Re: Gcc 1.39 and X386 1.1b (and xfig 2.0 p10)
Keywords: gcc, x11, x386
Message-ID: <64426@bigtex.cactus.org>
Date: 29 Jun 91 17:59:06 GMT
References: <1991Jun27.173040.3890@mav.com> <1991Jun27.201622.22286@serval.net.wsu.edu>
Reply-To: james@bigtex.cactus.org (James Van Artsdalen)
Organization: Institute of Applied Cosmology, Austin TX
Lines: 60

In <1991Jun27.201622.22286@serval.net.wsu.edu>, hlu@yoda.eecs.wsu.edu
	(Hongjiu Lu) wrote:

> I had the same problem regarding the floating point operation with
> gcc 1.39. I had to use cc instead of gcc for some floating point
> programs. Could anyone give us a clue?

If you have a program that fails with SIGFPE when compiled by gcc, but
does not do so with pcc, it is probably a gcc bug.

How to get gcc bugs fixed:

First, verify that the bug exists in stock gcc 1.40 from FSF, using
/bin/as and not gas (gas bugs should be reported too, but those aren't
compiler bugs).  In particular, don't use Bloom's COFF-generating-gas
changes.  It's not that those changes don't work - I have no way of
duplicating such cases.

If the program is fairly small and self-contained (ie, not the X server),
send me the source and script(1) output of how to run the program.  If
you don't have script(1), use emacs shell-mode or something similar.
It may be necessary to send me the preprocessed source files instead
of the .c source, if your /usr/include files differ from mine.

If the faulting program is large, or if you cannot send the complete
source, or it is not a program I can run here, then you'll need to
figure out which instruction that gcc generated incorrectly, and what
it should have been.  I can then use the preprocessed source for that
file to fix the bug.

To figure out bugs, run the program under gdb.  When the program
faults, do "info float" to see where the faulting instruction was, and
use the command

	x/i 0x1234

to see what the failing instruction was (where 0x1234 is the program
counter that info float displays).  "info float" also prints the state
of the FP stack.

There are two common cases:

1. The 387 stack is full, and the failing instruction is an "fld" or
   "fild".  This bug is sometimes hard to track.  The bug may not be
   in the function that failed, but in another function somewhere else
   altogether.  Finding this usually means stepping through the
   program, looking for a place where the 387 stack gets pushed deeper
   than two deep (that's as deep stock gcc 1.40 should get normally).

2. The 387 stack is empty, and the failing instruction is not a load.
   These are usually easier to track.  In the instructions prior to
   the failing opcode, there will probably be a store & pop
   instruction that should only have been a store.  Or perhaps a
   function call that was expected to return a FP value, but did not.

Either way, you'll probably narrow the fault down to an fst that
should have been an fstp, or an fstp that should have been an fst.
-- 
James R. Van Artsdalen          james@bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789