Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!rutgers!sunybcs!boulder!hao!oddjob!gargoyle!ihnp4!cuae2!killer!jfh
From: jfh@killer.UUCP (The Beach Bum)
Newsgroups: comp.lang.c
Subject: Trouble with Greenhill's C compiler
Message-ID: <1241@killer.UUCP>
Date: Wed, 29-Jul-87 16:12:18 EDT
Article-I.D.: killer.1241
Posted: Wed Jul 29 16:12:18 1987
Date-Received: Sat, 1-Aug-87 15:28:51 EDT
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 33
Keywords: c optimizing bugs compiler greenhills

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