🚀 go-pugleaf

Folks,

We have been having some problems with gcc/gdb and were hoping you
could help. We have some code that works under the Sun ANSI C compiler
acc but does not work under gcc. The only distinguishing feature of
this code (that we can figure) is the use of large automatic arrays of
doubles. Since this code is somewhat long and part of a much larger
executable I tried to test the problem with a much smaller
self-contained program:

------------------------8<------Cut---Here------>8-----------------------------

#define	MAX_ITER	10000
#define MAX_ASIZE	170

int
main(int argc, char *argv[])
{
	int	i;
	double	a[MAX_ASIZE]; 

	for(i = 0; i < MAX_ITER; i++) {
		
	}

}

------------------------8<------Cut---Here------>8-----------------------------


We are compiling and running on Sun Sparcs. The compilation and link
lines are as follows:

   gcc -ansi -c -Dsparc -DLINT_ARGS -g  -sun4 -c  gtest.c
   gcc -ansi -o gtest  gtest.o -L/usr/lang/SC1.0 -lF77 -lm /usr/5lib/libc.a

The program runs fine (in fact much more complicated versions with
more automatic arrays of doubles run as well) when the macro MAX_ASIZE
is set to 170 or 171. However, when brought into the debugger (gdb) with
MAX_ASIZE set to 171 setting a breakpoint on main and then running the
program results in the following:

	Current directory is /user/keithw/gtest/
	Reading symbols from gtest...done.
	(gdb) b main
	Breakpoint 1 at 0x229c: file gtest.c, line 10.
	(gdb) r
	Starting program: /user/keithw/gtest/gtest 

	Breakpoint 1, main (Cannot access memory at address 0x44.
	(gdb) f 0
	argc=#0  main (Cannot access memory at address 0x44.
	(gdb) show version
	GDB 4.0, Copyright (C) 1991 Free Software Foundation, Inc.

Obviously it is the "(Cannot access memory at address 0x44" that is
disturbing. Note that when MAX_ASIZE is 170 the debugging session runs
with no problems as follows:

	(gdb) b main
	Breakpoint 1 at 0x229c: file gtest.c, line 10.
	(gdb) r
	Starting program: /user/keithw/gtest/gtest

	Breakpoint 1, main (argc=1, argv=0xf7fff62c) at gtest.c:10

I do not know if the problems that we have with our production code is
related to this but if any of you experts have any ideas I would
welcome any help you could give.


By the way, here is the verbose compile/link listing if it helps:

gcc -ansi -v -c -Dsparc -DLINT_ARGS -g  -sun4 -c  gtest.c
gcc version 1.37.1
 /usr/local/lib/gcc-cpp -v -Dsparc -DLINT_ARGS -undef -D__GNUC__ \
	-trigraphs -$ -D__STRICT_ANSI__ -D__sparc__ \
        -D__sun__ -D__unix__ gtest.c /usr/tmp/cca29450.cpp
GNU CPP version 1.37.1
 /usr/local/lib/gcc-cc1 /usr/tmp/cca29450.cpp -quiet\
	 -dumpbase gtest.c -g -ansi -version -o /usr/tmp/cca29450.s
GNU C version 1.37.1 (sparc) compiled by GNU C version 1.39.
default target switches: -mfpu -mepilogue
 as -o gtest.o /usr/tmp/cca29450.s
gcc -ansi -v -o gtest  gtest.o -L/usr/lang/SC1.0 -lF77 -lm  /usr/5lib/libc.a
gcc version 1.37.1
 /usr/local/lib/gcc-ld -o gtest -e start -dc -dp /lib/crt0.o \
	-L/usr/lang/SC1.0 gtest.o -lF77 -lm /usr/5lib/libc.a \
	/usr/local/lib/gcc-gnulib -lc /usr/local/lib/gcc-gnulib


I'll try to read the gnu.* tree for the next couple of weeks but if
you could email answers directly I would be most appreciative.

Thanks for your time,
KW

Keith Weintraub (KW) -- Citicorp |    I told you a trillion times:
keithw@Citicorp.COM              |	"Don't exaggerate."
uunet!ccorp!keithw               |
-- 
Keith Weintraub (KW) -- Citicorp |    I told you a trillion times:
keithw@Citicorp.COM              |	"Don't exaggerate."
uunet!ccorp!keithw               |