Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!lavaca.uh.edu!karazm.math.uh.edu!jet
From: jet@karazm.math.uh.edu ("J. Eric Townsend")
Newsgroups: comp.lang.c
Subject: Re: Wierd core dump on sparc-1
Message-ID: <1991Jan24.234658.27689@lavaca.uh.edu>
Date: 24 Jan 91 23:46:58 GMT
References: <1991Jan23.232300.3698@lavaca.uh.edu> <1991Jan24.061653.22785@tkou02.enet.dec.com> <1991Jan24.214110.1478@cec1.wustl.edu>
Sender: nntppost@lavaca.uh.edu (NNTP Posting Service)
Organization: University of Houston -- Department of Mathematics
Lines: 31

In article <1991Jan24.214110.1478@cec1.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes:
>>Good idea.  Why didn't you try it before posting?

I did, several different ways.  I was going to try it some *more*...

>In article <1991Jan24.061653.22785@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes:
>	I had the same problem a couple of weeks ago. (also on a sparc
>	1+ station). I was using a number of large arrays. by keeping
>	the same array sizes and changing their type from double to 
>	float the problem disappear. So for some reason it seems it has
>	something to do with big arrays.


Aha!  I'm using big arrays of doubles as well.    A quick
:%s/double/float/g
produced a source, that when compiled, did *not* dump core.

For the file that uses doubles, I've also discovered that
cc -o foo foo.c
produces a file that *doesn't* dump core, while
cc -c foo.c
ld -o foo foo.o
produces a file that *does* dump core.

Looks like a 4.0.3c compiler bug.  We go to 4.1.1 in a couple of weeks,
so maybe I'll just wait and see if that "fixes" the problem.

--
J. Eric Townsend     Internet: jet@uh.edu    Bitnet: jet@UHOU
Systems Mangler - UH Dept. of Mathematics - (713) 749-2120
Motorola skates on Intel's head!