jfh@killer.UUCP (The Beach Bum) (07/29/87)
I am having trouble with a piece of code that works just fine with 10 or so other C compilers but causes core dumps when compiled with Greenhills. Unfortunately I can't post the code (license stuff), but I can tell you all about it ... :-) (I wrote it when I worked for the guy that owns it, and now it has come back to haunt me ;-) The piece of code implements sparse matrices with elements of varying types. Pointers to the elements are stored in an array of arrays to pointers to things and the types are handled in the same ugly manner. Question is: is there any kind of problem with Greenhills expecting some more normal pointer behavior? I added fprintf's to help debug the code, and it only behaves when the fprintf's are in place. Keep in mind that this code runs on MS-DOS, VMS, BSD-UNIX and USG-UNIX engines, so it ain't some simple problem with the code, it has to be some wierd interaction with the compiler. Also, the answer needs to be something other than `turn off the optimizer' since that's the reason I bought the compiler in the first place. Here is the setup we have: Plexus P/95 Plexus Sys5.2 - USG Unix 5.2 based 68020 Greenhill's C compiler, -O and -20 flags used. - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) (07/31/87)
in article <1241@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) says: > > I am having trouble with a piece of code that works just fine with > 10 or so other C compilers but causes core dumps when compiled with > Greenhills. Unfortunately I can't post the code (license stuff), but ... Have you tried looking at the assembly code it generates (I assume for your 68020 system)? At my last job we used a Green Hills C cross-compiler from VAX/VMS to 68000, and some of the "optimized" code it emitted was truly astounding (as in bletcherous). When it worked it worked quite well, but it wasn't without flaws. Caveat: this was a coupla years back. Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
wvpj@vax1.UUCP (Marc Parmet) (08/03/87)
In article <1241@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: >I am having trouble with a piece of code that works just fine with >10 or so other C compilers but causes core dumps when compiled with >Greenhills.... > >The piece of code implements sparse matrices with elements of varying >types. Pointers to the elements are stored in an array of arrays to >pointers to things and the types are handled in the same ugly manner. > I will briefly describe a problem I had with this Greenhill's C compiler using MPW on a Mac 2.0. Apple Tech Support verified this as a "genuine" bug. Assignments to static variables, or to variables declared outside any function, from a function result, may not work. The code I had trouble with is something like this: static extended n; extern extended sin(); void func() { n = sin(1.0); /* Fails */ } A fix was this: static extended n; extern extended sin(); void func() { extended temp; temp = sin(1.0); n = temp; } From you're brief description of the problem, it's hard to tell if this is the solution, but give it a shot... Marc Parmet Dept. of Mathematics Cornell University6
john@frog.UUCP (John Woods, Software) (08/04/87)
In article <1241@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes: I> I am having trouble with a piece of code that works just fine with N> 10 or so other C compilers but causes core dumps when compiled with C> Greenhills. ... The piece of code implements sparse matrices with elements L> of varying types. Pointers to the elements are stored in an array of arrays U> to pointers to things and the types are handled in the same ugly manner. D> E> Question is: is there any kind of problem with Greenhills expecting D> some more normal pointer behavior? I added fprintf's to help debug the > code, and it only behaves when the fprintf's are in place. T> E> Keep in mind that this code runs on MS-DOS, VMS, BSD-UNIX and USG-UNIX X> engines, so it ain't some simple problem with the code, it has to be T> some wierd interaction with the compiler. We have Greenhills C 1.8.0 here. I can't offhand think of anything in our past experience with Greenhills C that would cause problems (especially given the tremendously vague nature of the description), but it isn't bug free (of course). However, if I were you, I would NOT, repeat ***NOT*** rule out "some simple problem with the code". I have seen FAR too much code that compiled and ran fine on other systems that Greenhills gave wierd results for -- because the code really was WORNG! [sic] Some things to watch especially hard for: Greenhills allocates local variables in a different stack order of most compilers; e.g. if you declare int m,n,o,p; char x[10]; char y[10]; on a 4.3 VAX (for instance, as it is handy), the stack offsets from FP are (in order) -4, -8, -12, -16, -26, -36. GHC assigns them -16, -12, -8, -4, -26, -36. Makes no difference? You have no idea how much I have suffered from programs that make some subtle (mis)use of that feature... Oh, by the way, GHC won't allocate variables that aren't used -- thus further confusing the stack ordering. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA "The Unicorn is a pony that has been tragically disfigured by radiation burns." -- Dr. Science
nw@palladium.UUCP (Neil Webber) (08/04/87)
In article <15213@teknowledge-vaxc.ARPA>, mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) writes: > ... At my last job we used a Green Hills C cross-compiler > from VAX/VMS to 68000, and some of the "optimized" code it emitted was > truly astounding (as in bletcherous). When it worked it worked quite > well, but it wasn't without flaws. Caveat: this was a coupla years back. I've used an early version of Green Hills (1.6.3) and later versions (1.8.0). (4.x BSD, but I don't think the code generation changes between different hosts). The early versions were very buggy and generated very poor code in some circumstances. The newer versions don't suffer from those problems. Disclaimer: I have no connection with Green Hills. -- Neil Webber / Palladium Data Systems / (No longer confused with Jordan Marsh) Marlboro MA, 01752 {linus!alliant, harvard!cfisun}!palladium!nw
jfh@killer.UUCP (The Beach Bum) (08/06/87)
In article <1542@frog.UUCP>, john@frog.UUCP writes: > In article <1241@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes: > E> Question is: is there any kind of problem with Greenhills expecting > D> some more normal pointer behavior? I added fprintf's to help debug the > > code, and it only behaves when the fprintf's are in place. > > However, if I were you, I would NOT, repeat ***NOT*** rule out > "some simple problem with the code". I have seen FAR too much code that > compiled and ran fine on other systems that Greenhills gave wierd results > for -- because the code really was WORNG! The problem seems to be that the Ultrix compiler barfs on a cast that is needed in this routine, so the cast was taken out shortly after the code was written. There seems to be a bug in the Ultrix compiler having to do with casts. The GH compiler barfs without the cast. Why, who knows. Since it ain't my code anymore I'm just going to leave the cast in and not bother trying to figure out what is up with the compiler. Note: Why any of the other code isn't affected is beyond me. You couldn't get this program through lint if your life depended on it ... - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993