From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29953 invoked by alias); 16 Sep 2003 13:43:38 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 29946 invoked by uid 48); 16 Sep 2003 13:43:38 -0000 Date: Tue, 16 Sep 2003 14:30:00 -0000 Message-ID: <20030916134338.29944.qmail@sources.redhat.com> From: "warren_baird at cimmetry dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20030911203619.12252.warren_baird@cimmetry.com> References: <20030911203619.12252.warren_baird@cimmetry.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/12252] ICE on very large source file : GC problem? X-Bugzilla-Reason: CC X-SW-Source: 2003-09/txt/msg01230.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12252 ------- Additional Comments From warren_baird at cimmetry dot com 2003-09-16 13:43 ------- I guess I wasn't clear enough in my post yesterday --- sorry... Originally I had 2 files - tmp1.ii and tmp2.ii - both over 110k lines long --- tmp1.ii segfaults with the default parameters, and with the parameters set to 0. tmp2.ii doesn't segfault with the default params, but does with them set to 0... However, I've tried chopping tmp2.ii down to get a smaller test case and haven't had any luck --- I cut out the last 30k lines, and it took over two hours, but compiled successfully. I might eventually be able to cut it down to a workable test case, but it's going to take a *long* time... I also tried Michael's suggestion - the results were more interesting... We only hit the 'timevar_push' line in ggc_collect once before things crash. Here's the traceback: Breakpoint 1, ggc_collect () at ../../gcc-3.3.1/gcc/ggc-page.c:1711 (gdb) where #0 ggc_collect () at ../../gcc-3.3.1/gcc/ggc-page.c:1711 #1 0x00236820 in rest_of_compilation (decl=0xf8013700) at ../../gcc-3.3.1/gcc/toplev.c:2553 #2 0x00093d90 in genrtl_finish_function (fn=0xf8013700) at ../../gcc-3.3.1/gcc/cp/semantics.c:2589 #3 0x00093a2c in expand_body (fn=0xf8013700) at ../../gcc-3.3.1/gcc/cp/semantics.c:2412 #4 0x0004860c in instantiate_decl (d=0xf8013700, defer_ok=0) at ../../gcc-3.3.1/gcc/cp/pt.c:10492 #5 0x000489b0 in instantiate_pending_templates () at ../../gcc-3.3.1/gcc/cp/pt.c:10569 #6 0x0005bd1c in finish_file () at ../../gcc-3.3.1/gcc/cp/decl2.c:2803 #7 0x00069000 in yyparse () at parse.y:489 #8 0x000b0cc4 in c_common_parse_file (set_yydebug=0) at ../../gcc-3.3.1/gcc/c-lex.c:159 #9 0x0023600c in compile_file () at ../../gcc-3.3.1/gcc/toplev.c:2130 #10 0x0023b44c in do_compile () at ../../gcc-3.3.1/gcc/toplev.c:5383 #11 0x0023b50c in toplev_main (argc=13, argv=0xffbef7a4) at ../../gcc-3.3.1/gcc/toplev.c:5414 So I assume this means that cc1 is crashing on the very first attempt to garbage collect?