Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!rutgers!husc6!necntc!frog!john
From: john@frog.UUCP (John Woods, Software)
Newsgroups: comp.lang.c
Subject: Re: Trouble with Greenhill's C compiler
Message-ID: <1542@frog.UUCP>
Date: Mon, 3-Aug-87 19:23:00 EDT
Article-I.D.: frog.1542
Posted: Mon Aug  3 19:23:00 1987
Date-Received: Thu, 6-Aug-87 01:42:42 EDT
References: <1241@killer.UUCP>
Organization: Superfrog Heaven [ CRDS, Framingham MA ]
Lines: 40
Keywords: c optimizing bugs compiler greenhills
Summary: oh really?

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