Date:	Sat, 08 Sep 2001 21:18:11 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De
Message-Id:	<7704-Sat08Sep2001211808+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	sandmann AT clio DOT rice DOT edu, pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com
In-reply-to:	<69117341E6B@HRZ1.hrz.tu-darmstadt.de>
	(ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De)
Subject:	Re: gcc-301 difficulty
References:	<3B9899F8 DOT 17555 DOT 21743F AT localhost> from "pavenis AT lanet DOT lv" at Sep 07, 2001 09:57:12 AM <69117341E6B AT HRZ1 DOT hrz DOT tu-darmstadt DOT de>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
> Organization: Darmstadt University of Technology
> Date: Sat, 8 Sep 2001 19:29:49 +0200
> 
> > Does it crash if you run cc1 individually (not from GCC? do gcc -v and
> > manually do the CC1 step)
> Yes, it crashes in the same way.

This probably means the nested invocation is not an issue.  Selector
freeing probably also isn't relevant, since it only happens inside
dosexec.c, and cc1.exe alone doesn't invoke any programs, so doesn't
call dosexec, right?

> make.exe[2]: Entering directory `z:/tmp/sed/lib'
> gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c getopt1.c
> gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c getopt.c
> Exiting due to signal SIGSEGV
> General Protection Fault at eip=00240a7d
> eax=000002a7 ebx=00240b84 ecx=00000010 edx=00000000 esi=00240b84 edi=ffffffa4
> ebp=00000fbc esp=00000fbc program=D:\CVS\LIB\GCC-LIB\DJGPP\3.01\CC1.EXE
> cs: sel=029f  base=82cc7000  limit=004affff
> ds: sel=02a7  base=82cc7000  limit=004affff
> es: sel=02a7  base=82cc7000  limit=004affff
> fs: sel=027f  base=00022720  limit=0000ffff
> gs: sel=02b7  base=00000000  limit=0010ffff
> ss: sel=0173  invalid
> App stack: [00346978..002c6978]  Exceptn stack: [002c63c0..002c4480]
> 
> Call frame traceback EIPs:
>   0x00240a7d ___djgpp_exception_table+301
> 
> 2) Compiling sed30280 on plain DOS:
> d:/cvs/bin/make.exe  all-recursive
[...]
> Exiting due to signal SIGSEGV
> Page fault at eip=001c0df1, error=0004
> eax=00000002 ebx=00000008 ecx=00000002 edx=00000000 esi=00000002 edi=0019a59c
> ebp=003461e8 esp=00345cc0 program=d:/cvs/bin/../lib/gcc-lib/djgpp/3.01/cc1.exe
> cs: sel=0227  base=105b0000  limit=004affff
> ds: sel=022f  base=105b0000  limit=004affff
> es: sel=022f  base=105b0000  limit=004affff
> fs: sel=020f  base=0003b540  limit=0000ffff
> gs: sel=023f  base=00000000  limit=0010ffff
> ss: sel=022f  base=105b0000  limit=004affff
> App stack: [00346978..002c6978]  Exceptn stack: [002c63c0..002c4480]
> 
> Call frame traceback EIPs:
>   0x001c0df1 _find_reloads+737, line ?? of reload.c

Note that the two crashes seem very different.  Also note that the
first crash was on the second compilation, so the first compilation
ran to completion without crashing.

> Silly programs like:
> 
> #include <stdio.h>
> main()
> {
>   int i;
>   for (i=0;i<10000;i++)
>     printf("i=%i\n",i);
> }
> 
> can be compiled without difficulty.

This probably means that you need a sufficiently complex source file
to cause a crash.  Hardware problems usually manifest themselves like
that, but we still have to explain why older versions of GCC didn't
crash.

Andris, what significant changes were introduced into GCC between v3.0
and 3.0.1?  (I mean not only DJGPP-specific changes.)

- Raw text -