[m-dev.] building the current compiler on sparc

[Fergus Henderson]

On 24-Feb-1999, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> 
> For 3 or 4 days now, I don't manage to build the current Mercury compiler on
> sparc (SunOS cripure 5.7 Generic sun4u sparc SUNW,Ultra-250). Whereas on
> Linux (Linux averell 2.0.34 #2 Thu Jul 9 10:57:48 EST 1998 i686 unknown), it
> works ok. 

Which version of gcc are you using?
Also, just to make absolutely sure, when you say the "current"
Mercury compiler, do you mean the latest version in the cvs repository?
And what mmc options are you compiling it with?

> MERCURY_ALL_C_INCL_DIRS="-I../trace -I../runtime" ../scripts/mgnuc --grade asm_fast.gc     -I../boehm_gc        -c rl_code.c -o rl_code.o
> rl_code.c: In function `rl_code_module6':
> rl_code.c:45173: warning: right shift count >= width of type
> rl_code.c:45175: warning: right shift count >= width of type
> rl_code.c:45177: warning: right shift count >= width of type
> rl_code.c:45179: warning: right shift count >= width of type
> sparc-sun-solaris2.6-gcc: Internal compiler error: program cc1 got fatal signal 11
> gmake[1]: *** [rl_code.o] Error 1
> gmake[1]: Leaving directory `/home/swann/d02/lande/jahier/mercury/compiler'
> gmake: *** [compiler] Error 2
> [12:11]%
> 
> Note: at that stage on Linux (i.e. when the compilation arrives to the point
> "rl_code.c:45173: warning: right shift count >= width of type ...." messages
> are displayed), the machine is swapping very hard.
> 
> Does it fail to compile on sparcs because the the machine is overloaded ?

It's possible.  Fatal signal 11 is SIGSEGV.  This can result from
the program running out of C stack space.

> What can I do ?

Check your ulimits e.g. using the sh/bash command `ulimit -a'.
Examine all the limits, but pay particular attention to the stack limit.
Examine the resources used by the cc1 process when it dies, using
`ps' and/or `top'.

You can do "mmake EXTRA_CFLAGS='-v -Q -save-temps'"; this will show you
the exact way in which cc1 is being invoked.  Then you can invoke cc1
manually, inside gdb; presuming that your cc1 excecutable hasn't been
stripped, this will allow you to see exactly where it is dying. 
By examining the location and the values of the nearby data, you should
be able to see why it is dying, e.g. due to stack overflow, dereferencing
a null pointer, or whatever.

(If your cc1 has been stripped, you can download the gcc source and do

	zcat gcc*.tar.gz | tar -xf - &&
	cd gcc* &&
	sh configure &&
	make CFLAGS=-g cc1

to create one with debugging information.)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.