stu@mav.com (Stu Donaldson) (06/28/91)
After bringing up Roell's X386 1.1b, using gcc 1.39 (standard distribution, not the stuff with direct support for COFF and gdb), I tried to get xfig up. I grabbed the latest copy I could find, xfig 2.0 pl10 and it compiled first try without any problems. However, upon running it, it would crash the server when I tried to draw any lines. After turnning debug on in the server, and compiling with '-g' I was able to trace it down to the function miWideSegment (ddx/mi/miwideline.c) where it was getting a floating point exception error. I used sdb to find the values in the offending line of code, could not find what was causing the error. I then recompiled miwideline.c with the stock C compiler (cc) and linked X386 using gcc, and my problem was solved. There is apparently a bug in how gcc is dealing with floating point. I had one earlier occasion using xeyes where it failed with a floating point exception when using gcc. I'm running an ACER 1100/33, 80387, and ISC 2.2. I haven't had any other noticeable problems, but then I hadn't been using gcc for very long either. So has anyone else seen this problem? Is it possible that I have something wrong with my configuration? When I made gcc, everything worked fine, and it passed the various tests that it came with. Anyway, hope this helps if anyone else out there has a similar problem. -- Stu -- ----------------------------------------------------------------------- Stu Donaldson "Can't you understand what I'm saying?" stu@mav.com "What happened? Did you Fail Telepathy?"
hlu@yoda.eecs.wsu.edu (Hongjiu Lu) (06/28/91)
In article <1991Jun27.173040.3890@mav.com> stu@mav.com writes: >After bringing up Roell's X386 1.1b, using gcc 1.39 (standard distribution, >not the stuff with direct support for COFF and gdb), I tried to get >xfig up. I grabbed the latest copy I could find, xfig 2.0 pl10 and >it compiled first try without any problems. However, upon running >it, it would crash the server when I tried to draw any lines. > >After turnning debug on in the server, and compiling with '-g' I >was able to trace it down to the function miWideSegment (ddx/mi/miwideline.c) >where it was getting a floating point exception error. I used sdb >to find the values in the offending line of code, could not find what >was causing the error. I then recompiled miwideline.c with the stock >C compiler (cc) and linked X386 using gcc, and my problem was solved. > >There is apparently a bug in how gcc is dealing with floating point. >I had one earlier occasion using xeyes where it failed with a floating >point exception when using gcc. > >I'm running an ACER 1100/33, 80387, and ISC 2.2. I haven't had any other >noticeable problems, but then I hadn't been using gcc for very long either. > >So has anyone else seen this problem? Is it possible that I have >something wrong with my configuration? When I made gcc, everything >worked fine, and it passed the various tests that it came with. > >Anyway, hope this helps if anyone else out there has a similar problem. > > -- Stu -- >----------------------------------------------------------------------- >Stu Donaldson "Can't you understand what I'm saying?" >stu@mav.com "What happened? Did you Fail Telepathy?" > 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? Thanks. H.J. Lu
scotte@applix.com (Scott Evernden) (06/28/91)
In article <1991Jun27.173040.3890@mav.com> stu@mav.com writes: >After bringing up Roell's X386 1.1b, using gcc 1.39 (standard distribution, >not the stuff with direct support for COFF and gdb), I tried to get >xfig up. I grabbed the latest copy I could find, xfig 2.0 pl10 and >it compiled first try without any problems. However, upon running >it, it would crash the server when I tried to draw any lines. Oh fud. You mean that bug is still in there? I've been trying to get my hands on 1.1b in the hopes that maybe that particular annoyance went away. I guess I don't need to try so hard now... I've mentioned this problem here before, but hain't seen any followups. Maybe Mr. Roell can take a look at this when he has a chance?? -scott
ghelmer@dsuvax.uucp (Guy Helmer) (06/29/91)
In <1991Jun27.201622.22286@serval.net.wsu.edu> hlu@yoda.eecs.wsu.edu (Hongjiu Lu) writes: >In article <1991Jun27.173040.3890@mav.com> stu@mav.com writes: >>After bringing up Roell's X386 1.1b, using gcc 1.39 (standard distribution, >>not the stuff with direct support for COFF and gdb), I tried to get >>xfig up. I grabbed the latest copy I could find, xfig 2.0 pl10 and >>it compiled first try without any problems. However, upon running >>it, it would crash the server when I tried to draw any lines. >> [...] >>I then recompiled miwideline.c with the stock >>C compiler (cc) and linked X386 using gcc, and my problem was solved. >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? Did you run gcc with the '-traditional' switch? If not, I'd immediately suspect problems with the way floating point values are passed/returned to/from functions, since it seems likely gcc will pass floats as floats instead of doubles (like other ANSI C compilers) if the -traditional switch isn't specified. I've found the changes between K&R and ANSI to be a big problem for code that was unintentionally written to depend on K&R's parameter passing and function value returning schemes. Then again, I could still be under the influence of being recently married :-) and this might have nothing to do with your problems. >Thanks. >H.J. Lu -- Guy Helmer, Dakota State University Computing Services helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu, ghelmer@dsuvax.dsu.edu "Everybody need a soft filter / Everybody need reverse polarity" - Rush
glenn@suphys.physics.su.OZ.AU (Glenn Geers) (06/29/91)
From article <1224@applix.com>, by scotte@applix.com (Scott Evernden): > In article <1991Jun27.173040.3890@mav.com> stu@mav.com writes: >>After bringing up Roell's X386 1.1b, using gcc 1.39 (standard distribution, >>not the stuff with direct support for COFF and gdb), I tried to get >>xfig up. I grabbed the latest copy I could find, xfig 2.0 pl10 and >>it compiled first try without any problems. However, upon running >>it, it would crash the server when I tried to draw any lines. > > Oh fud. You mean that bug is still in there? I've been trying to get > my hands on 1.1b in the hopes that maybe that particular annoyance went > away. I guess I don't need to try so hard now... > > I've mentioned this problem here before, but hain't seen any followups. > Maybe Mr. Roell can take a look at this when he has a chance?? > > -scott I had this problem as well. But after recompiling the server without any network stuff (Esix 3.2 rev D - sockets are a little weird) and modifying gcc so that statics do not go into the data segment but into the bss it all worked fine. The way gcc pads code out to page boundaries is also different from the way cc does it. Straight gcc/gas does not use 0x90 as the opcode for a nop. This also leads to problems building shlibs where the start address must be known in advance. Currently I'm using gcc 1.40 with the aforementioned changes and xfig 2.10 works fine. BTW I'm only using X386 1.1a - is 1.1b faster or what? Glenn -- ___________________________________________________________________________ Glenn Geers | "So when it's over, | we're back to people. Department of Theoretical Physics | Just to prove that human touch The University of Sydney | can have no equal." Sydney NSW 2006 Australia | - Basia Trzetrzelewska, 'Prime Time TV' | Phone: +61 2 692-3241 (voice) |_________________________________________ +61 2 660-2903 (fax) | | glenn@qed.physics.su.oz.au | #include <standard_disclaimer.h> | ----------------------------------------------------------------------------
tony@mcrsys.UUCP (Tony Becker) (06/29/91)
From article <1991Jun27.173040.3890@mav.com>, by stu@mav.com (Stu Donaldson): > There is apparently a bug in how gcc is dealing with floating point. > I had one earlier occasion using xeyes where it failed with a floating > point exception when using gcc. > > So has anyone else seen this problem? Is it possible that I have > something wrong with my configuration? When I made gcc, everything > worked fine, and it passed the various tests that it came with. > > -- Stu -- > ----------------------------------------------------------------------- > Stu Donaldson "Can't you understand what I'm saying?" > stu@mav.com "What happened? Did you Fail Telepathy?" I am using gcc 1.39 and X11R4 on SVR4. mi code is not part of Roell's code. I have seen an indication of floating point problems once, but I have had a running server, and re-build many more over the last 6 months with no problems. The one time I saw a floating point error was when I mixed cc and gcc floating point code. So Don't. Make sure ALL code that uses floating point is compiled and linked with gcc. -- tony ,....
james@bigtex.cactus.org (James Van Artsdalen) (06/30/91)
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