This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
egcs-CVS19981005, rs6000 bootstrap still dies in stage1 libgcc2.a
- To: egcs-bugs at cygnus dot com
- Subject: egcs-CVS19981005, rs6000 bootstrap still dies in stage1 libgcc2.a
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Mon, 5 Oct 1998 13:52:38 -0400 (EDT)
Hi,
Any progress on the rs6000 bootstraps? I'm still having problems
with last night's checkout even if all I use for BOOT_CFLAGS is '-g
-mminimal-toc'. (It never gets far enough to use those flags anyway.)
The bootstrap crashes during stage1 when building libgcc2.a.
> echo ${name}; \
> ./xgcc -B./ -O2 -DIN_GCC -g -I./include -g1 -DIN_LIBGCC2 \
> -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I./config -I./../include -c \
> -DL${name} ./libgcc2.c -o ${name}.o; \
> if [ $? -eq 0 ] ; then true; else exit 1; fi; \
> ar rc tmplibgcc2.a ${name}.o; \
> rm -f ${name}.o; \
> done
> _muldi3
> _divdi3
> xgcc: Internal compiler error: program cc1 got fatal signal 11
> make[4]: *** [libgcc2.a] Error 1
I ran dbx and it seems to be dying in malloc().
> (dbx) where
> malloc_y(??) at 0xd0004098
> malloc(??) at 0xd0001a80
> xmalloc(size = 56), line 2162 in "toplev.c"
> unnamed block $b2936, line 219 in "alloca.c"
> alloca(0x30), line 219 in "alloca.c"
> cse_insn(0x20112edc, 0x0), line 6292 in "cse.c"
> unnamed block $b1377, line 8783 in "cse.c"
> cse_basic_block(0x201009c8, 0x20109210, 0x2ff210ac, 0x0), line 8783 in "cse.c"
> cse_main(0x200fb4a8, 0x168, 0x1, 0x0), line 8626 in "cse.c"
> rest_of_compilation(decl = 0x200f65a8), line 3578 in "toplev.c"
> finish_function(0x0), line 7181 in "c-decl.c"
> yyparse(), line 313 in "c-parse.y"
> compile_file(name = "/tmp/cc0Ha9Pb.i"), line 2788 in "toplev.c"
> main(argc = 10, argv = 0x2ff21a30), line 4862 in "toplev.c"
This is the stage1 compiler built with cc, so I don't think its
a gcc code generation problem. Instead, one of the optimization
routines might be trashing malloc's space. (It may help to build gcc
with a malloc debugging tool...)
Makefile builds libgcc2.a with -O2. I reran _divdi3 by hand
with only -O and it succeeded. So perhaps the guilty code is in one of
the -O2 based routines.
Hope this helps.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Icon CMT Corp.