This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

egcs-CVS19981005, rs6000 bootstrap still dies in stage1 libgcc2.a


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]