-finline core dumps egcs-1.0.1...

[Mike Simons]

Jeff Law wrote:
> We don't need the source file trimmed down.  The .ii file, the
> target name and the compile time options you're using should be
> all we need to look at the problem.

  I was concerned because the .ii file is 400k ... I didn't want to 
just blast the egcs-bugs list with something that big.  I did manage 
to trim the .ii down to 3000 lines and still produce the problem...
then it got obvious that something about the 'distance' between the
goto and it's label was the problem because if I deleted *any* of
about 500 statements in main the problem went away.

I sent out my final report to Jeff and this list: 
  Subject: Re: -finline core dumps egcs-1.0.1...
  To: law@cygnus.com
  Date: Mon, 23 Feb 1998 06:37:37 -0500 (EST)
  Cc: egcs-bugs@cygnus.com
  Content-Length: 88672     

  but never saw it come back in from the list.  I'm going to try posting 
it again, this time without the gzip/uuencoded .ii file at the end.
I suspect it is too big to get through the list... Anyone who wants the 
85k compressed version of that file just let me know and I'll forward it 
to you...

  Does this list nuke messages beyond a certain size?

==============================================


Jeff,

Jeff Law wrote:
> Note that you might be running into a case where you're running
> out of memory.  We've fixed many problems in this area, but some
> might remain.

  You're right!

  It's not exactly "running out of memory" ... it was artificially 
running out of stack... that artificial limit can't be increased
on some machines.

sched.c function schedule_block() is dumping core:
  GNU gdb 4.16.85
  2645      i = max_reg_num ();
  (gdb) n
  2646      reg_last_uses = (rtx *) alloca (i * sizeof (rtx));
  (gdb) 
  2647      bzero ((char *) reg_last_uses, i * sizeof (rtx));
  (gdb) p i
  $1 = 23480
  (gdb) p i * sizeof(rtx)
  $2 = 93920
  (gdb) p reg_last_uses
  $3 = (rtx *) 0xef818628
  (gdb) n
  2648      reg_last_sets = (rtx *) alloca (i * sizeof (rtx));
  (gdb) 

  Program received signal SIGSEGV, Segmentation fault.
  0x2bd078 in schedule_block (b=0, file=0x0) at sched.c:2648
  2648      reg_last_sets = (rtx *) alloca (i * sizeof (rtx));


default ulimit -a...
  core file size (blocks)  unlimited
  data seg size (kbytes)   2097148
  file size (blocks)       unlimited
  stack size (kbytes)      8192
  cpu time (seconds)       unlimited
  pipe size (512 bytes)    10
  open files               64
  virtual memory (kbytes)  2097151

by raising my stack limit on the sparc that code compiled fine...

  linux users default to a 8192k limit, this is their hard limit.
to date I have not tried compiling mySQL on Intel Linux, as I would
need to install glibc <shutter ;>.


  alloca on the sparcs _appears_ to SIGSEGV as soon as you run out of
stack... instead of returning NULL.  Even if it did return NULL, adding
in all the checks and a backup plan for that would be a royal pain.
If this had been making malloc/free calls, there would not have been a
problem.  gcc makes pretty extensive use of alloca about 495 references
(in *.c) there are only about 518 of mallocs.

  - Would changing the allocs in sched.h to malloc/free calls be 
    an acceptable fix?
  - Or are there much better ways to fix this?

-- 

    Thanks,
      Mike Simons
      Science Applications International Corporation
      msimons@saic1.com                  703-925-5674


command:
c++ -DMYSQL_SERVER \
  -DDEFAULT_MYSQL_HOME="\"/usr/raid/local/sparc/egcs-1.0.1\"" \
  -DDATADIR="\"/opt/mysql/data\"" \
  -DSHAREDIR="\"/usr/raid/local/sparc/egcs-1.0.1/share/mysql\"" \
  -DHAVE_CONFIG_H -I./../include -I./../regex \
  -I. -I../include -I.. -I.  -O -O9 -pipe -g \
  -fno-implicit-templates -DDBUG_OFF -c sql_yacc.cc -v

output:
Reading specs from \
  /usr/raid/local/sparc/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.90.23/specs
gcc version egcs-2.90.23 980102 (egcs-1.0.1 release)
/usr/raid/local/sparc/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.90.23/cpp \
  -lang-c++ -v -I./../include -I./../regex -I. -I../include -I.. -I. \
  -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=90 \
  -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ \
  -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix \
  -Asystem(unix) -Asystem(svr4) -D__EXCEPTIONS -D__OPTIMIZE__ -g \
  -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) -DMYSQL_SERVER \
  -DDEFAULT_MYSQL_HOME="/usr/raid/local/sparc/egcs-1.0.1" \
  -DDATADIR="/opt/mysql/data" \
  -DSHAREDIR="/usr/raid/local/sparc/egcs-1.0.1/share/mysql" \
  -DHAVE_CONFIG_H -DDBUG_OFF sql_yacc.cc |
/usr/raid/local/sparc/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.90.23/cc1plus \
  -quiet -dumpbase sql_yacc.cc -g -O -O9 -version \
  -fno-implicit-templates -o - |
/usr/raid/local/sparc/sparc-sun-solaris2.5/bin/as -V -Qy -s -o sql_yacc.o -
GNU CPP version egcs-2.90.23 980102 (egcs-1.0.1 release) (sparc)
GNU C++ version egcs-2.90.23 980102 (egcs-1.0.1 release) (sparc-sun-solaris2.5) compiled by GNU C version 2.7.2.2.
#include "..." search starts here:
#include <...> search starts here:
 ../include
 ../regex
 .
 ../include
 ..
 .
 /usr/raid/local/sparc/egcs-1.0.1/include/g++
 /usr/raid/local/sparc/egcs-1.0.1/include
 /usr/raid/local/sparc/egcs-1.0.1/sparc-sun-solaris2.5/include
 /usr/raid/local/sparc/egcs-1.0.1/lib/gcc-lib/sparc-sun-solaris2.5/\
   egcs-2.90.23/include
 /usr/include
End of search list.
GNU assembler version 970915 (sparc-sun-solaris2.5), using BFD version 970915
c++: Internal compiler error: program cc1plus got fatal signal 11
{standard input}: Assembler messages:
{standard input}:527: Warning: end of file in string: inserted '"'
{standard input}:995: Warning: .stabs: Missing comma

  this is down to 85k... 
would everyone perfer I send the raw files in the future and not a 
compressed version?

gzip, uuencoded copy of sql_yacc.ii follows:
================================================
[deleted because my last post never came back, i suspect it was too big]