* Checking failure building arm-elf @ 2003-03-06 11:22 Richard Earnshaw 2003-03-06 12:25 ` Andreas Schwab 0 siblings, 1 reply; 28+ messages in thread From: Richard Earnshaw @ 2003-03-06 11:22 UTC (permalink / raw) To: gcc-bugs, gcc-patches; +Cc: Richard.Earnshaw This is new since yesterday. Building arm-elf now fails with an internal check failure: /work/rearnsha/gnu/egcs/gcc/xgcc -shared-libgcc -B/work/rearnsha/gnu/egcs/g cc/ -nostdinc++ -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src/.libs -nostdinc -B/work/rearnsha/gnu/egcs/arm-elf/newlib/ -isystem /work/rearnsha/gnu/egcs/arm-elf/newlib/targ-include -isystem /home/rearnsha/gnusrc/egcs-cross/newlib/libc/include -B/work/rearnsha/gnu/install/arm-elf/bin/ -B/work/rearnsha/gnu/install/arm- elf/lib/ -isystem /work/rearnsha/gnu/install/arm-elf/include -isystem /work/rearnsha/gnu/install/arm-elf/sys-include -L/work/rearnsha/gnu/egcs/ld -c -S -O2 -g -O2 conftest.C 1>&5 configure: In function `void foo()': configure:3967: internal compiler error: tree check: expected class 'd', have 't ' (record_type) in decl_assembler_name, at tree.c:151 Testcase: struct S { ~S(); }; void bar(); void foo() { S s; bar(); } ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-06 11:22 Checking failure building arm-elf Richard Earnshaw @ 2003-03-06 12:25 ` Andreas Schwab 2003-03-06 13:12 ` Jan Hubicka 2003-03-06 13:12 ` Hans-Peter Nilsson 0 siblings, 2 replies; 28+ messages in thread From: Andreas Schwab @ 2003-03-06 12:25 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-bugs, gcc-patches Richard Earnshaw <rearnsha@arm.com> writes: |> This is new since yesterday. Building arm-elf now fails with an internal |> check failure: |> |> /work/rearnsha/gnu/egcs/gcc/xgcc -shared-libgcc -B/work/rearnsha/gnu/egcs/g |> cc/ -nostdinc++ -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src |> -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src/.libs -nostdinc |> -B/work/rearnsha/gnu/egcs/arm-elf/newlib/ -isystem |> /work/rearnsha/gnu/egcs/arm-elf/newlib/targ-include -isystem |> /home/rearnsha/gnusrc/egcs-cross/newlib/libc/include |> -B/work/rearnsha/gnu/install/arm-elf/bin/ -B/work/rearnsha/gnu/install/arm- |> elf/lib/ -isystem /work/rearnsha/gnu/install/arm-elf/include -isystem |> /work/rearnsha/gnu/install/arm-elf/sys-include -L/work/rearnsha/gnu/egcs/ld |> -c -S -O2 -g -O2 conftest.C 1>&5 |> configure: In function `void foo()': |> configure:3967: internal compiler error: tree check: expected class 'd', |> have 't |> ' (record_type) in decl_assembler_name, at tree.c:151 Same on ia64. Since this is called from cgraph_rtl_info via cgraph_node at cgraph.c:88 I suspect it's the last change in this file that broke this. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-06 12:25 ` Andreas Schwab @ 2003-03-06 13:12 ` Jan Hubicka 2003-03-06 13:12 ` Hans-Peter Nilsson 1 sibling, 0 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-06 13:12 UTC (permalink / raw) To: Andreas Schwab; +Cc: Jan Hubicka, gcc-bugs, gcc-patches > Richard Earnshaw <rearnsha@arm.com> writes: > > |> This is new since yesterday. Building arm-elf now fails with an internal > |> check failure: > |> > |> /work/rearnsha/gnu/egcs/gcc/xgcc -shared-libgcc -B/work/rearnsha/gnu/egcs/g > |> cc/ -nostdinc++ -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src > |> -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src/.libs -nostdinc > |> -B/work/rearnsha/gnu/egcs/arm-elf/newlib/ -isystem > |> /work/rearnsha/gnu/egcs/arm-elf/newlib/targ-include -isystem > |> /home/rearnsha/gnusrc/egcs-cross/newlib/libc/include > |> -B/work/rearnsha/gnu/install/arm-elf/bin/ -B/work/rearnsha/gnu/install/arm- > |> elf/lib/ -isystem /work/rearnsha/gnu/install/arm-elf/include -isystem > |> /work/rearnsha/gnu/install/arm-elf/sys-include -L/work/rearnsha/gnu/egcs/ld > |> -c -S -O2 -g -O2 conftest.C 1>&5 > |> configure: In function `void foo()': > |> configure:3967: internal compiler error: tree check: expected class 'd', > |> have 't > |> ' (record_type) in decl_assembler_name, at tree.c:151 > > Same on ia64. Since this is called from cgraph_rtl_info via cgraph_node at > cgraph.c:88 I suspect it's the last change in this file that broke this. Oops. I will look into this after the lesson (in 1.5hour) Honza > > Andreas. > > -- > Andreas Schwab, SuSE Labs, schwab@suse.de > SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 NĂźrnberg > Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-06 12:25 ` Andreas Schwab 2003-03-06 13:12 ` Jan Hubicka @ 2003-03-06 13:12 ` Hans-Peter Nilsson 2003-03-06 13:31 ` Jan Hubicka 1 sibling, 1 reply; 28+ messages in thread From: Hans-Peter Nilsson @ 2003-03-06 13:12 UTC (permalink / raw) To: Andreas Schwab; +Cc: Jan Hubicka, gcc-bugs, gcc-patches On Thu, 6 Mar 2003, Andreas Schwab wrote: > Richard Earnshaw <rearnsha@arm.com> writes: > > |> This is new since yesterday. Building arm-elf now fails with an internal > |> check failure: > |> > |> /work/rearnsha/gnu/egcs/gcc/xgcc -shared-libgcc -B/work/rearnsha/gnu/egcs/g > |> cc/ -nostdinc++ -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src > |> -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src/.libs -nostdinc > |> -B/work/rearnsha/gnu/egcs/arm-elf/newlib/ -isystem > |> /work/rearnsha/gnu/egcs/arm-elf/newlib/targ-include -isystem > |> /home/rearnsha/gnusrc/egcs-cross/newlib/libc/include > |> -B/work/rearnsha/gnu/install/arm-elf/bin/ -B/work/rearnsha/gnu/install/arm- > |> elf/lib/ -isystem /work/rearnsha/gnu/install/arm-elf/include -isystem > |> /work/rearnsha/gnu/install/arm-elf/sys-include -L/work/rearnsha/gnu/egcs/ld > |> -c -S -O2 -g -O2 conftest.C 1>&5 > |> configure: In function `void foo()': > |> configure:3967: internal compiler error: tree check: expected class 'd', > |> have 't > |> ' (record_type) in decl_assembler_name, at tree.c:151 > > Same on ia64. Since this is called from cgraph_rtl_info via cgraph_node at > cgraph.c:88 I suspect it's the last change in this file that broke this. Same on *all* other targets I try to build (except those failing before this point) for example: cris-axis-elf, mmix-knuth-mmixware, h8300-hitachi-hms, i960-unknown-coff, m32r-unknown-elf, mn10300-unknown-elf, d30v-unknown-elf, mcore-unknown-elf (though some usually fail *after* this point). Do thing bootstrap *anywhere else* than i686-pc-linux-gnu? Whatever the failing failing patch is, it should be ASAP fixed or reverted. I'll check by reverting the last cgraph.c patch locally. (Rant: Why can't people take the time to build and test their patches with at least *one* simulator chain besides their native machine, instead inconveniencing all other people? It's even a in the testing instructions! Though it's stated as an "encouragement", maybe it should be made a "requirement". mn10300-unknown-elf is a complete toolchain usually buildable and with few multilibs, mmix-knuth-mmixware too except you need the mmix simulator from Knuth's site, see readings.html.) brgds, H-P ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-06 13:12 ` Hans-Peter Nilsson @ 2003-03-06 13:31 ` Jan Hubicka 2003-03-06 14:29 ` Hans-Peter Nilsson ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-06 13:31 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Andreas Schwab, Jan Hubicka, gcc-bugs, gcc-patches > On Thu, 6 Mar 2003, Andreas Schwab wrote: > > > Richard Earnshaw <rearnsha@arm.com> writes: > > > > |> This is new since yesterday. Building arm-elf now fails with an internal > > |> check failure: > > |> > > |> /work/rearnsha/gnu/egcs/gcc/xgcc -shared-libgcc -B/work/rearnsha/gnu/egcs/g > > |> cc/ -nostdinc++ -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src > > |> -L/work/rearnsha/gnu/egcs/arm-elf/libstdc++-v3/src/.libs -nostdinc > > |> -B/work/rearnsha/gnu/egcs/arm-elf/newlib/ -isystem > > |> /work/rearnsha/gnu/egcs/arm-elf/newlib/targ-include -isystem > > |> /home/rearnsha/gnusrc/egcs-cross/newlib/libc/include > > |> -B/work/rearnsha/gnu/install/arm-elf/bin/ -B/work/rearnsha/gnu/install/arm- > > |> elf/lib/ -isystem /work/rearnsha/gnu/install/arm-elf/include -isystem > > |> /work/rearnsha/gnu/install/arm-elf/sys-include -L/work/rearnsha/gnu/egcs/ld > > |> -c -S -O2 -g -O2 conftest.C 1>&5 > > |> configure: In function `void foo()': > > |> configure:3967: internal compiler error: tree check: expected class 'd', > > |> have 't > > |> ' (record_type) in decl_assembler_name, at tree.c:151 I've just reproduced it in the clean checkout. Not sure why it didn't crashed in my previous tree. I am commiting the attached patch as obvious that should fix the problem. The cgraph codes confused methods and nested functions... Sorry for the breakage. Index: cgraph.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cgraph.c,v retrieving revision 1.6 diff -c -3 -p -r1.6 cgraph.c *** cgraph.c 5 Mar 2003 22:19:31 -0000 1.6 --- cgraph.c 6 Mar 2003 13:20:05 -0000 *************** cgraph_node (decl) *** 98,104 **** cgraph_nodes = node; cgraph_n_nodes++; *slot = node; ! if (DECL_CONTEXT (decl)) { node->origin = cgraph_node (DECL_CONTEXT (decl)); node->next_nested = node->origin->nested; --- 98,104 ---- cgraph_nodes = node; cgraph_n_nodes++; *slot = node; ! if (DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL) { node->origin = cgraph_node (DECL_CONTEXT (decl)); node->next_nested = node->origin->nested; ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-06 13:31 ` Jan Hubicka @ 2003-03-06 14:29 ` Hans-Peter Nilsson 2003-03-07 2:44 ` David Edelsohn 2003-03-07 3:04 ` David Edelsohn 2 siblings, 0 replies; 28+ messages in thread From: Hans-Peter Nilsson @ 2003-03-06 14:29 UTC (permalink / raw) To: Jan Hubicka; +Cc: Andreas Schwab, gcc-bugs, gcc-patches On Thu, 6 Mar 2003, Jan Hubicka wrote: > > > Richard Earnshaw <rearnsha@arm.com> writes: > > > |> configure: In function `void foo()': > > > |> configure:3967: internal compiler error: tree check: expected class 'd', > > > |> have 't > > > |> ' (record_type) in decl_assembler_name, at tree.c:151 > > I've just reproduced it in the clean checkout. Not sure why it didn't > crashed in my previous tree. I am commiting the attached patch as > obvious that should fix the problem. Thanks, that seems to have fixed it. brgds, H-P ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-06 13:31 ` Jan Hubicka 2003-03-06 14:29 ` Hans-Peter Nilsson @ 2003-03-07 2:44 ` David Edelsohn 2003-03-08 13:05 ` Jan Hubicka 2003-03-07 3:04 ` David Edelsohn 2 siblings, 1 reply; 28+ messages in thread From: David Edelsohn @ 2003-03-07 2:44 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches I am still seeing this failure on powerpc-ibm-aix4.3.3.0 after applying the recent cgraph.c:cgraph_node patch: /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/gcc/xgcc -shared-libgcc -B/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/gcc/ -nostdinc++ -L/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/src -L/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/src/.libs -B/gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/bin/ -B/gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/lib/ -isystem /gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/include -isystem /gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/sys-include -pthread -nostdinc++ -I/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.3.0 -I/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include -I/gcc/dje/src/libstdc++-v3/libsupc++ -I/gcc/dje/src/libstdc++-v3/libmath -O2 -g -O2 -g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -c /gcc/dje/src/libstdc++-v3/src/codecvt.cc -DPIC -o .libs/codecvt.o /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include/bits/codecvt.h: In constructor `std::codecvt<char, char, char*>::codecvt(long unsigned int)': /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include/bits/codecvt.h:122: internal compiler error: tree check: expected class 'd', have 't' (record_type) in decl_assembler_name, at tree.c:151 Please submit a full bug report, ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-07 2:44 ` David Edelsohn @ 2003-03-08 13:05 ` Jan Hubicka 0 siblings, 0 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-08 13:05 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, gcc-patches > I am still seeing this failure on powerpc-ibm-aix4.3.3.0 after > applying the recent cgraph.c:cgraph_node patch: > > /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/gcc/xgcc -shared-libgcc > -B/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/gcc/ -nostdinc++ > -L/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/src > -L/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/src/.libs > -B/gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/bin/ > -B/gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/lib/ > -isystem > /gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/include > -isystem > /gcc/dje/install/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/sys-include > -pthread -nostdinc++ > -I/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include/powerpc-ibm-aix4.3.3.0 > -I/gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include > -I/gcc/dje/src/libstdc++-v3/libsupc++ -I/gcc/dje/src/libstdc++-v3/libmath > -O2 -g -O2 -g -O2 -fno-implicit-templates -Wall -Wno-format -W > -Wwrite-strings -Winline -fdiagnostics-show-location=once -c > /gcc/dje/src/libstdc++-v3/src/codecvt.cc -DPIC -o .libs/codecvt.o > /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include/bits/codecvt.h: > In > constructor `std::codecvt<char, char, char*>::codecvt(long unsigned > int)': > /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/pthread/libstdc++-v3/include/bits/codecvt.h:122: > internal compiler error: tree > check: expected class 'd', have 't' (record_type) in > decl_assembler_name, at > tree.c:151 > Please submit a full bug report, Even with --enable-checking=gcac libstdc++ builds fine for me... I will try to implement the code to avoid garbage collecting anyway, and send you to try it out. Honza ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-06 13:31 ` Jan Hubicka 2003-03-06 14:29 ` Hans-Peter Nilsson 2003-03-07 2:44 ` David Edelsohn @ 2003-03-07 3:04 ` David Edelsohn 2003-03-07 11:30 ` Jan Hubicka 2 siblings, 1 reply; 28+ messages in thread From: David Edelsohn @ 2003-03-07 3:04 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches I have confirmed that the cgraph patch still is the culprit. If I revert the cgraph_rtl_info patch, the cc1plus ICE is fixed. David ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-07 3:04 ` David Edelsohn @ 2003-03-07 11:30 ` Jan Hubicka 2003-03-07 16:45 ` David Edelsohn 2003-03-07 16:50 ` David Edelsohn 0 siblings, 2 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-07 11:30 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, gcc-patches > I have confirmed that the cgraph patch still is the culprit. If I > revert the cgraph_rtl_info patch, the cc1plus ICE is fixed. Can you send me a backtrace of what happens? It is really strange as I think I now check the presence of DECL in all paths into cgraph_node. Honza > > David ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-07 11:30 ` Jan Hubicka @ 2003-03-07 16:45 ` David Edelsohn 2003-03-07 16:55 ` Jan Hubicka 2003-03-07 16:50 ` David Edelsohn 1 sibling, 1 reply; 28+ messages in thread From: David Edelsohn @ 2003-03-07 16:45 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches >>>>> Jan Hubicka writes: Jan> Can you send me a backtrace of what happens? It is really strange as I Jan> think I now check the presence of DECL in all paths into cgraph_node. #0 0xd0188154 in exit () from /usr/lib/libc.a(shr.o) #1 0x1000b270 in internal_error ( msgid=0x1050662c "tree check: expected %s, have %s in %s, at %s:%d") at /gcc/dje/src/gcc/diagnostic.c:1200 #2 0x1001d4d0 in tree_check_failed (node=0x0, code=BLOCK, file=0x0, line=1059, function=0x104f26a8 "write_source_name") at /gcc/dje/src/gcc/tree.c:4557 #3 0x103c8944 in write_source_name (identifier=0x200c3d54) at /gcc/dje/src/gcc/cp/mangle.c:1060 #4 0x103c73e4 in write_name (decl=0x3029a880, ignore_local_scope=-266058584) at /gcc/dje/src/gcc/cp/mangle.c:725 #5 0x103c9928 in write_local_name (function=0x3029a180, local_entity=0x3029a880, entity=0x3029a880) at /gcc/dje/src/gcc/cp/mangle.c:1356 #6 0x103c7404 in write_name (decl=0x3029a880, ignore_local_scope=-266058584) at /gcc/dje/src/gcc/cp/mangle.c:751 #7 0x103c6ff8 in write_encoding (decl=0x3029a880) at /gcc/dje/src/gcc/cp/mangle.c:656 #8 0x103cce68 in mangle_decl_string (decl=0x3029a880) at /gcc/dje/src/gcc/cp/mangle.c:2383 #9 0x103cd140 in mangle_decl (decl=0x3029a880) at /gcc/dje/src/gcc/cp/mangle.c:2405 #10 0x1000cda0 in decl_assembler_name (decl=0x3029a880) at /gcc/dje/src/gcc/tree.c:152 #11 0x103003f8 in eq_node (p1=0x1, p2=0x305efe00) at /gcc/dje/src/gcc/cgraph.c:73 #12 0x10020de4 in htab_find_slot_with_hash (htab=0x20130b88, element=0x305efe00, hash=101670040, insert=INSERT) at /gcc/dje/src/libiberty/hashtab.c:500 #13 0x103004cc in cgraph_node (decl=0x305efe00) at /gcc/dje/src/gcc/cgraph.c:88 #14 0x10300a04 in cgraph_rtl_info (decl=0x305efe00) at /gcc/dje/src/gcc/cgraph.c:216 #15 0x102f92c8 in flags_from_decl_or_type (exp=0x305efe00) at /gcc/dje/src/gcc/calls.c:802 #16 0x102fc420 in expand_call (exp=0x3076f990, target=0x0, ignore=1) at /gcc/dje/src/gcc/calls.c:2263 #17 0x102d3a74 in expand_expr (exp=0x3076f990, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /gcc/dje/src/gcc/expr.c:7742 #18 0x102b4e40 in expand_expr_stmt_value (exp=0x3076f990, want_value=-266058584, maybe_last=0) at /gcc/dje/src/gcc/stmt.c:2191 #19 0x10092ef4 in genrtl_expr_stmt_value (expr=0x3076f990, want_value=0, maybe_last=0) at /gcc/dje/src/gcc/c-semantics.c:358 #20 0x100957c4 in expand_stmt (t=0x3076f960) at /gcc/dje/src/gcc/c-semantics.c:822 #21 0x10094d88 in genrtl_compound_stmt (t=0x3076f918) at /gcc/dje/src/gcc/c-semantics.c:727 #22 0x1009540c in expand_stmt (t=0x3076f918) at /gcc/dje/src/gcc/c-semantics.c:841 #23 0x10094d88 in genrtl_compound_stmt (t=0x3076f888) at /gcc/dje/src/gcc/c-semantics.c:727 #24 0x1009540c in expand_stmt (t=0x3076f888) at /gcc/dje/src/gcc/c-semantics.c:841 #25 0x1008a64c in c_expand_expr (exp=0x3076f8b8, target=0x0, tmode=VOIDmode, modifier=0) at /gcc/dje/src/gcc/c-common.c:4325 #26 0x1032f35c in cxx_expand_expr (exp=0x3076f8b8, target=0x0, tmode=VOIDmode, modifier=0) at /gcc/dje/src/gcc/cp/expr.c:130 #27 0x102d1e4c in expand_expr (exp=0x3076f8b8, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /gcc/dje/src/gcc/expr.c:9404 #28 0x102d25d4 in expand_expr (exp=0x30823f00, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /gcc/dje/src/gcc/expr.c:6830 #29 0x102b4e40 in expand_expr_stmt_value (exp=0x30823f00, want_value=-266058584, maybe_last=0) at /gcc/dje/src/gcc/stmt.c:2191 #30 0x10092ef4 in genrtl_expr_stmt_value (expr=0x30823f00, want_value=0, maybe_last=1) at /gcc/dje/src/gcc/c-semantics.c:358 #31 0x10095898 in expand_stmt (t=0x306e01f8) at /gcc/dje/src/gcc/c-semantics.c:875 #32 0x10094d88 in genrtl_compound_stmt (t=0x306e01b0) at /gcc/dje/src/gcc/c-semantics.c:727 #33 0x1009540c in expand_stmt (t=0x306e01b0) at /gcc/dje/src/gcc/c-semantics.c:841 #34 0x10093394 in genrtl_if_stmt (t=0x30823720) at /gcc/dje/src/gcc/c-semantics.c:412 #35 0x10095780 in expand_stmt (t=0x30823720) at /gcc/dje/src/gcc/c-semantics.c:837 #36 0x10094d88 in genrtl_compound_stmt (t=0x306e00d8) at /gcc/dje/src/gcc/c-semantics.c:727 #37 0x1009540c in expand_stmt (t=0x306e00d8) at /gcc/dje/src/gcc/c-semantics.c:841 #38 0x10094d88 in genrtl_compound_stmt (t=0x306e0060) at /gcc/dje/src/gcc/c-semantics.c:727 #39 0x1009540c in expand_stmt (t=0x306e0060) at /gcc/dje/src/gcc/c-semantics.c:841 #40 0x1008a64c in c_expand_expr (exp=0x306e0078, target=0x0, tmode=VOIDmode, modifier=0) at /gcc/dje/src/gcc/c-common.c:4325 #41 0x1032f35c in cxx_expand_expr (exp=0x306e0078, target=0x0, tmode=VOIDmode, modifier=0) at /gcc/dje/src/gcc/cp/expr.c:130 #42 0x102d1e4c in expand_expr (exp=0x306e0078, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /gcc/dje/src/gcc/expr.c:9404 #43 0x102d25d4 in expand_expr (exp=0x30823de0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /gcc/dje/src/gcc/expr.c:6830 #44 0x102b4e40 in expand_expr_stmt_value (exp=0x30823de0, want_value=-266058584, maybe_last=0) at /gcc/dje/src/gcc/stmt.c:2191 #45 0x10092ef4 in genrtl_expr_stmt_value (expr=0x30823de0, want_value=0, maybe_last=1) at /gcc/dje/src/gcc/c-semantics.c:358 #46 0x10095898 in expand_stmt (t=0x30861498) at /gcc/dje/src/gcc/c-semantics.c:875 #47 0x10094d88 in genrtl_compound_stmt (t=0x3086a408) at /gcc/dje/src/gcc/c-semantics.c:727 #48 0x1009540c in expand_stmt (t=0x3086a408) at /gcc/dje/src/gcc/c-semantics.c:841 #49 0x1008a64c in c_expand_expr (exp=0x308614b0, target=0x30006400, tmode=VOIDmode, modifier=0) at /gcc/dje/src/gcc/c-common.c:4325 #50 0x1032f35c in cxx_expand_expr (exp=0x308614b0, target=0x30006400, tmode=VOIDmode, modifier=0) at /gcc/dje/src/gcc/cp/expr.c:130 #51 0x102d1e4c in expand_expr (exp=0x308614b0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /gcc/dje/src/gcc/expr.c:9404 #52 0x102b4e40 in expand_expr_stmt_value (exp=0x308614b0, want_value=-266058584, maybe_last=0) at /gcc/dje/src/gcc/stmt.c:2191 #53 0x10092ef4 in genrtl_expr_stmt_value (expr=0x308614b0, want_value=0, maybe_last=0) at /gcc/dje/src/gcc/c-semantics.c:358 #54 0x100957c4 in expand_stmt (t=0x30861510) at /gcc/dje/src/gcc/c-semantics.c:822 #55 0x10094d88 in genrtl_compound_stmt (t=0x3086a2d0) at /gcc/dje/src/gcc/c-semantics.c:727 #56 0x1009540c in expand_stmt (t=0x3086a2d0) at /gcc/dje/src/gcc/c-semantics.c:841 #57 0x10094d88 in genrtl_compound_stmt (t=0x3086a288) at /gcc/dje/src/gcc/c-semantics.c:727 #58 0x1009540c in expand_stmt (t=0x3086a288) at /gcc/dje/src/gcc/c-semantics.c:841 #59 0x1009d568 in expand_body (fn=0x30987180) at /gcc/dje/src/gcc/cp/semantics.c:2414 #60 0x10132ba4 in instantiate_decl (d=0x30987180, defer_ok=273250384) at /gcc/dje/src/gcc/cp/pt.c:10896 #61 0x10133148 in instantiate_pending_templates () at /gcc/dje/src/gcc/cp/pt.c:10973 #62 0x1013df28 in finish_file () at /gcc/dje/src/gcc/cp/decl2.c:2594 #63 0x10407634 in yyparse () at /gcc/dje/src/gcc/cp/parser.c:14659 #64 0x103d7fc0 in c_common_parse_file (set_yydebug=1) at /gcc/dje/src/gcc/c-lex.c:154 #65 0x10001864 in compile_file () at /gcc/dje/src/gcc/toplev.c:2188 #66 0x10008260 in do_compile (no_backend=0) at /gcc/dje/src/gcc/toplev.c:5530 #67 0x1000837c in toplev_main (argc=0, argv=0x2ff2261c) at /gcc/dje/src/gcc/toplev.c:5570 #68 0x10000378 in main (argc=1, argv=0xf02444a8) at /gcc/dje/src/gcc/main.c:37 #69 0x10000204 in __start () ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-07 16:45 ` David Edelsohn @ 2003-03-07 16:55 ` Jan Hubicka 0 siblings, 0 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-07 16:55 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, gcc-patches > >>>>> Jan Hubicka writes: > > Jan> Can you send me a backtrace of what happens? It is really strange as I > Jan> think I now check the presence of DECL in all paths into cgraph_node. > > #0 0xd0188154 in exit () from /usr/lib/libc.a(shr.o) > #1 0x1000b270 in internal_error ( > msgid=0x1050662c "tree check: expected %s, have %s in %s, at %s:%d") > at /gcc/dje/src/gcc/diagnostic.c:1200 > #2 0x1001d4d0 in tree_check_failed (node=0x0, code=BLOCK, file=0x0, > line=1059, function=0x104f26a8 "write_source_name") > at /gcc/dje/src/gcc/tree.c:4557 > #3 0x103c8944 in write_source_name (identifier=0x200c3d54) > at /gcc/dje/src/gcc/cp/mangle.c:1060 > #4 0x103c73e4 in write_name (decl=0x3029a880, ignore_local_scope=-266058584) > at /gcc/dje/src/gcc/cp/mangle.c:725 > #5 0x103c9928 in write_local_name (function=0x3029a180, > local_entity=0x3029a880, entity=0x3029a880) > at /gcc/dje/src/gcc/cp/mangle.c:1356 > #6 0x103c7404 in write_name (decl=0x3029a880, ignore_local_scope=-266058584) > at /gcc/dje/src/gcc/cp/mangle.c:751 > #7 0x103c6ff8 in write_encoding (decl=0x3029a880) > at /gcc/dje/src/gcc/cp/mangle.c:656 > #8 0x103cce68 in mangle_decl_string (decl=0x3029a880) > at /gcc/dje/src/gcc/cp/mangle.c:2383 > #9 0x103cd140 in mangle_decl (decl=0x3029a880) > at /gcc/dje/src/gcc/cp/mangle.c:2405 > #10 0x1000cda0 in decl_assembler_name (decl=0x3029a880) > at /gcc/dje/src/gcc/tree.c:152 This is really weird. I tought that the assembler name is always evaulated in expand_call, so this should be safe. I wonder why it is not. I will try to dig into the documentation early tomorrow (I have to leave in 3 minutes from now) Thanks for the info and soery for the breakage, hope to fix it tomorrow. Honza ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-07 11:30 ` Jan Hubicka 2003-03-07 16:45 ` David Edelsohn @ 2003-03-07 16:50 ` David Edelsohn 2003-03-07 22:39 ` Jan Hubicka 1 sibling, 1 reply; 28+ messages in thread From: David Edelsohn @ 2003-03-07 16:50 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches #15 0x102f92c8 in flags_from_decl_or_type (exp=0x305efe00) at /gcc/dje/src/gcc/calls.c:802 802 struct cgraph_rtl_info *i = cgraph_rtl_info (exp); (gdb) print exp $3 = 0x305efe00 (gdb) pt <function_decl 305efe00 __base_ctor type <method_type 305dce00 type <void_type 30015f80 void type_6 VOID align 8 symtab -11 alias set -1 pointer_to_this <pointer_type 30017000>> type_6 TI size <integer_cst 3000aca0 constant 128> unit size <integer_cst 3000aec0 constant 16> align 128 symtab 0 alias set -1 method basetype <record_type 302d3c80 ios_base> arg-types <tree_list 3033a7b0 side-effects value <pointer_type 302d3d00> chain <tree_list 3001b408 tree_2 value <void_type 30015f80 void>>> pointer_to_this <pointer_type 30736480>> addressable used public protected in_system_header external SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 context <record_type 302d3c80 ios_base> abstract_origin <function_decl 305ef380 ios_base> arguments <parm_decl 305efe80 this type <pointer_type 305d8880 type <record_type 302d3c80 ios_base> readonly unsigned DI size <integer_cst 3000af20 constant 64> unit size <integer_cst 3000af80 constant 8> align 64 symtab 0 alias set -1> readonly unsigned in_system_header DI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 size <integer_cst 3000af20 64> unit size <integer_cst 3000af80 8> align 64 context <function_decl 305efe00 __base_ctor> initial <pointer_type 305d8880> arg-type <pointer_type 305d8880>> (mem:SI (symbol_ref:DI ("_ZNSt8ios_baseC2Ev[DS]")) [0 S4 A8]) chain <function_decl 305efd00 __comp_ctor>> #14 0x10300a04 in cgraph_rtl_info (decl=0x305efe00) at /gcc/dje/src/gcc/cgraph.c:216 216 node = cgraph_node (decl); (gdb) print decl $4 = 0x305efe00 (gdb) pt <function_decl 305efe00 __base_ctor type <method_type 305dce00 type <void_type 30015f80 void type_6 VOID align 8 symtab -11 alias set -1 pointer_to_this <pointer_type 30017000>> type_6 TI size <integer_cst 3000aca0 constant 128> unit size <integer_cst 3000aec0 constant 16> align 128 symtab 0 alias set -1 method basetype <record_type 302d3c80 ios_base> arg-types <tree_list 3033a7b0 side-effects value <pointer_type 302d3d00> chain <tree_list 3001b408 tree_2 value <void_type 30015f80 void>>> pointer_to_this <pointer_type 30736480>> addressable used public protected in_system_header external SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 context <record_type 302d3c80 ios_base> abstract_origin <function_decl 305ef380 ios_base> arguments <parm_decl 305efe80 this type <pointer_type 305d8880 type <record_type 302d3c80 ios_base> readonly unsigned DI size <integer_cst 3000af20 constant 64> unit size <integer_cst 3000af80 constant 8> align 64 symtab 0 alias set -1> readonly unsigned in_system_header DI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 size <integer_cst 3000af20 64> unit size <integer_cst 3000af80 8> align 64 context <function_decl 305efe00 __base_ctor> initial <pointer_type 305d8880> arg-type <pointer_type 305d8880>> (mem:SI (symbol_ref:DI ("_ZNSt8ios_baseC2Ev[DS]")) [0 S4 A8]) chain <function_decl 305efd00 __comp_ctor>> #13 0x103004cc in cgraph_node (decl=0x305efe00) at /gcc/dje/src/gcc/cgraph.c:88 88 slot = (gdb) print decl $5 = 0x305efe00 (gdb) pt <function_decl 305efe00 __base_ctor type <method_type 305dce00 type <void_type 30015f80 void type_6 VOID align 8 symtab -11 alias set -1 pointer_to_this <pointer_type 30017000>> type_6 TI size <integer_cst 3000aca0 constant 128> unit size <integer_cst 3000aec0 constant 16> align 128 symtab 0 alias set -1 method basetype <record_type 302d3c80 ios_base> arg-types <tree_list 3033a7b0 side-effects value <pointer_type 302d3d00> chain <tree_list 3001b408 tree_2 value <void_type 30015f80 void>>> pointer_to_this <pointer_type 30736480>> addressable used public protected in_system_header external SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 context <record_type 302d3c80 ios_base> abstract_origin <function_decl 305ef380 ios_base> arguments <parm_decl 305efe80 this type <pointer_type 305d8880 type <record_type 302d3c80 ios_base> readonly unsigned DI size <integer_cst 3000af20 constant 64> unit size <integer_cst 3000af80 constant 8> align 64 symtab 0 alias set -1> readonly unsigned in_system_header DI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 size <integer_cst 3000af20 64> unit size <integer_cst 3000af80 8> align 64 context <function_decl 305efe00 __base_ctor> initial <pointer_type 305d8880> arg-type <pointer_type 305d8880>> (mem:SI (symbol_ref:DI ("_ZNSt8ios_baseC2Ev[DS]")) [0 S4 A8]) chain <function_decl 305efd00 __comp_ctor>> #10 0x1000cda0 in decl_assembler_name (decl=0x3029a880) at /gcc/dje/src/gcc/tree.c:152 152 (*lang_hooks.set_decl_assembler_name) (decl); (gdb) print decl $6 = 0x3029a880 (gdb) pt <result_decl 3029a880 type <template_type_parm 302a8c00 _RandomAccessIter type_0 type_6 VOID align 8 symtab 0 alias set 0 index 0 level 1 orig_level 1 chain <type_decl 302a8d80 _RandomAccessIter>> in_system_header VOID file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/stl_algo.h line 247 align 8 context <function_decl 3029a180 find_if>> ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-07 16:50 ` David Edelsohn @ 2003-03-07 22:39 ` Jan Hubicka 2003-03-08 4:02 ` David Edelsohn 0 siblings, 1 reply; 28+ messages in thread From: Jan Hubicka @ 2003-03-07 22:39 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, gcc-patches > #15 0x102f92c8 in flags_from_decl_or_type (exp=0x305efe00) > at /gcc/dje/src/gcc/calls.c:802 > 802 struct cgraph_rtl_info *i = cgraph_rtl_info (exp); > (gdb) print exp > $3 = 0x305efe00 > (gdb) pt > <function_decl 305efe00 __base_ctor > type <method_type 305dce00 > type <void_type 30015f80 void type_6 VOID > align 8 symtab -11 alias set -1 > pointer_to_this <pointer_type 30017000>> > type_6 TI > size <integer_cst 3000aca0 constant 128> > unit size <integer_cst 3000aec0 constant 16> > align 128 symtab 0 alias set -1 method basetype <record_type 302d3c80 ios_base> > arg-types <tree_list 3033a7b0 side-effects value <pointer_type 302d3d00> > chain <tree_list 3001b408 tree_2 value <void_type 30015f80 void>>> > pointer_to_this <pointer_type 30736480>> > addressable used public protected in_system_header external SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 context <record_type 302d3c80 ios_base> abstract_origin <function_decl 305ef380 ios_base> > arguments <parm_decl 305efe80 this > type <pointer_type 305d8880 type <record_type 302d3c80 ios_base> > readonly unsigned DI > size <integer_cst 3000af20 constant 64> > unit size <integer_cst 3000af80 constant 8> > align 64 symtab 0 alias set -1> > readonly unsigned in_system_header DI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 size <integer_cst 3000af20 64> unit size <integer_cst 3000af80 8> > align 64 context <function_decl 305efe00 __base_ctor> initial <pointer_type 305d8880> arg-type <pointer_type 305d8880>> > > (mem:SI (symbol_ref:DI ("_ZNSt8ios_baseC2Ev[DS]")) [0 S4 A8]) chain <function_decl 305efd00 __comp_ctor>> > > > #14 0x10300a04 in cgraph_rtl_info (decl=0x305efe00) > at /gcc/dje/src/gcc/cgraph.c:216 > 216 node = cgraph_node (decl); > (gdb) print decl > $4 = 0x305efe00 > (gdb) pt > <function_decl 305efe00 __base_ctor > type <method_type 305dce00 > type <void_type 30015f80 void type_6 VOID > align 8 symtab -11 alias set -1 > pointer_to_this <pointer_type 30017000>> > type_6 TI > size <integer_cst 3000aca0 constant 128> > unit size <integer_cst 3000aec0 constant 16> > align 128 symtab 0 alias set -1 method basetype <record_type 302d3c80 ios_base> > arg-types <tree_list 3033a7b0 side-effects value <pointer_type 302d3d00> > chain <tree_list 3001b408 tree_2 value <void_type 30015f80 void>>> > pointer_to_this <pointer_type 30736480>> > addressable used public protected in_system_header external SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 context <record_type 302d3c80 ios_base> abstract_origin <function_decl 305ef380 ios_base> > arguments <parm_decl 305efe80 this > type <pointer_type 305d8880 type <record_type 302d3c80 ios_base> > readonly unsigned DI > size <integer_cst 3000af20 constant 64> > unit size <integer_cst 3000af80 constant 8> > align 64 symtab 0 alias set -1> > readonly unsigned in_system_header DI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 size <integer_cst 3000af20 64> unit size <integer_cst 3000af80 8> > align 64 context <function_decl 305efe00 __base_ctor> initial <pointer_type 305d8880> arg-type <pointer_type 305d8880>> > > (mem:SI (symbol_ref:DI ("_ZNSt8ios_baseC2Ev[DS]")) [0 S4 A8]) chain <function_decl 305efd00 __comp_ctor>> > > > #13 0x103004cc in cgraph_node (decl=0x305efe00) at /gcc/dje/src/gcc/cgraph.c:88 > 88 slot = > (gdb) print decl > $5 = 0x305efe00 > (gdb) pt > <function_decl 305efe00 __base_ctor > type <method_type 305dce00 > type <void_type 30015f80 void type_6 VOID > align 8 symtab -11 alias set -1 > pointer_to_this <pointer_type 30017000>> > type_6 TI > size <integer_cst 3000aca0 constant 128> > unit size <integer_cst 3000aec0 constant 16> > align 128 symtab 0 alias set -1 method basetype <record_type 302d3c80 ios_base> > arg-types <tree_list 3033a7b0 side-effects value <pointer_type 302d3d00> > chain <tree_list 3001b408 tree_2 value <void_type 30015f80 void>>> > pointer_to_this <pointer_type 30736480>> > addressable used public protected in_system_header external SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 context <record_type 302d3c80 ios_base> abstract_origin <function_decl 305ef380 ios_base> > arguments <parm_decl 305efe80 this > type <pointer_type 305d8880 type <record_type 302d3c80 ios_base> > readonly unsigned DI > size <integer_cst 3000af20 constant 64> > unit size <integer_cst 3000af80 constant 8> > align 64 symtab 0 alias set -1> > readonly unsigned in_system_header DI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/ios_base.h line 664 size <integer_cst 3000af20 64> unit size <integer_cst 3000af80 8> > align 64 context <function_decl 305efe00 __base_ctor> initial <pointer_type 305d8880> arg-type <pointer_type 305d8880>> > > (mem:SI (symbol_ref:DI ("_ZNSt8ios_baseC2Ev[DS]")) [0 S4 A8]) chain <function_decl 305efd00 __comp_ctor>> > > > #10 0x1000cda0 in decl_assembler_name (decl=0x3029a880) > at /gcc/dje/src/gcc/tree.c:152 > 152 (*lang_hooks.set_decl_assembler_name) (decl); > (gdb) print decl > $6 = 0x3029a880 > (gdb) pt > <result_decl 3029a880 This is very puzzling.. from where the result_decl_comes from? Can you please check the p1 and p2 in eq_node? It seems to be that DECL_ASSEMBLER_NAME must have been executed for both of them already when they were inserted into the table, so I really don't understand why they are checked again... Thanks, Honza > type <template_type_parm 302a8c00 _RandomAccessIter type_0 type_6 VOID > align 8 symtab 0 alias set 0 > index 0 level 1 orig_level 1 > chain <type_decl 302a8d80 _RandomAccessIter>> > in_system_header VOID file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030306/powerpc-ibm-aix4.3.3.0/ppc64/libstdc++-v3/include/bits/stl_algo.h line 247 > align 8 context <function_decl 3029a180 find_if>> ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-07 22:39 ` Jan Hubicka @ 2003-03-08 4:02 ` David Edelsohn 2003-03-08 11:57 ` Jan Hubicka 2003-03-08 13:34 ` Jan Hubicka 0 siblings, 2 replies; 28+ messages in thread From: David Edelsohn @ 2003-03-08 4:02 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches >>>>> Jan Hubicka writes: Jan> This is very puzzling.. from where the result_decl_comes from? Jan> Can you please check the p1 and p2 in eq_node? Jan> It seems to be that DECL_ASSEMBLER_NAME must have been executed for both Jan> of them already when they were inserted into the table, so I really Jan> don't understand why they are checked again... Optimization may have been confusing the information. I recompiled cgraph.c without optimization. p1 is the cgraph_hash entry for the hash value provided. #4 0x10309fd0 in eq_node (p1=0x20133988, p2=0x305dd200) at /gcc/dje/src/gcc/cgraph.c:75 75 return ((DECL_ASSEMBLER_NAME (((struct cgraph_node *) p1)->decl)) == (gdb) print ((struct cgraph_node *) p1)->decl $9 = 0x30292600 (gdb) pt <pointer_type 30292600 type <record_type 30292580 binary_function<typename _Predicate::first_argument_type,typename _Predicate::second_argument_type,bool> type_0 type_5 type_6 VOID align 8 symtab 0 alias set -1 context <namespace_decl 3000cd80 std> n_parents 0 use_template=1 interface-unknown pointer_to_this <pointer_type 30292600> chain <type_decl 30292780 binary_function<typename _Predicate::first_argument_type,typename _Predicate::second_argument_type,bool>>> unsigned SI size <integer_cst 3000ad80 type <integer_type 30014d00 bit_size_type> constant 32> unit size <integer_cst 3000ade0 type <integer_type 30014c80 long unsigned int> constant 4> align 32 symtab 0 alias set -1> (gdb) print (tree) p2 $10 = (union tree_node *) 0x305dd200 (gdb) pt <function_decl 305dd200 operator>> type <method_type 305dd180 type <reference_type 305a4780 type <record_type 302d8900 basic_istream<char,std::char_traits<char> >> unsigned SI size <integer_cst 3000ad80 constant 32> unit size <integer_cst 3000ade0 constant 4> align 32 symtab 2253 alias set 21> DI size <integer_cst 3000ab00 constant 64> unit size <integer_cst 3000ad20 constant 8> align 64 symtab 0 alias set -1 method basetype <record_type 302d8900 basic_istream<char,std::char_traits<char> >> arg-types <tree_list 304a9090 side-effects value <pointer_type 302d8980> chain <tree_list 307a6450 value <reference_type 30602a00> chain <tree_list 3001a408 tree_2 value <void_type 30014f80 void>>>> pointer_to_this <pointer_type 30993e00>> addressable used public in_system_header external SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030307/powerpc-ibm-aix4.3.3.0/libstdc++-v3/include/bits/istream.tcc line 375 context <record_type 302d8900 basic_istream<char,std::char_traits<char> >> arguments <parm_decl 305dd380 this type <pointer_type 30646780 type <record_type 302d8900 basic_istream<char,std::char_traits<char> >> readonly unsigned SI size <integer_cst 3000ad80 32> unit size <integer_cst 3000ade0 4> align 32 symtab 0 alias set -1> readonly unsigned used in_system_header SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030307/powerpc-ibm-aix4.3.3.0/libstdc++-v3/include/bits/istream.tcc line 375 size <integer_cst 3000ad80 32> unit size <integer_cst 3000ade0 4> align 32 initial <pointer_type 30646780> arg-type <pointer_type 30646780> chain <parm_decl 305dd700 __n type <reference_type 30602a00> readonly unsigned used in_system_header SI file /gcc/dje/build/powerpc-ibm-aix4.3.3.0-20030307/powerpc-ibm-aix4.3.3.0/libstdc++-v3/include/bits/istream.tcc line 375 size <integer_cst 3000ad80 32> unit size <integer_cst 3000ade0 4> align 32 initial <reference_type 30602a00> arg-type <reference_type 30602a00>>> initial <block 308b7300> template-info 304a9150 (mem:SI (symbol_ref:SI ("_ZNSirsERf[DS]")) [0 S4 A8]) chain <function_decl 305dd900 operator>>>> ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-08 4:02 ` David Edelsohn @ 2003-03-08 11:57 ` Jan Hubicka 2003-03-08 13:34 ` Jan Hubicka 1 sibling, 0 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-08 11:57 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, gcc-patches > >>>>> Jan Hubicka writes: > > Jan> This is very puzzling.. from where the result_decl_comes from? > Jan> Can you please check the p1 and p2 in eq_node? > Jan> It seems to be that DECL_ASSEMBLER_NAME must have been executed for both > Jan> of them already when they were inserted into the table, so I really > Jan> don't understand why they are checked again... > > Optimization may have been confusing the information. I > recompiled cgraph.c without optimization. > > p1 is the cgraph_hash entry for the hash value provided. > > #4 0x10309fd0 in eq_node (p1=0x20133988, p2=0x305dd200) > at /gcc/dje/src/gcc/cgraph.c:75 > 75 return ((DECL_ASSEMBLER_NAME (((struct cgraph_node *) > p1)->decl)) == > (gdb) print ((struct cgraph_node *) p1)->decl > $9 = 0x30292600 > (gdb) pt > <pointer_type 30292600 This is the problem - there really should not be pointer_type in the hashtable. I guess only way how it can get in is via memory corruption - local declarations may get garbage collected and replaced by something else. I will try to reproduce it with GC checking. Honza ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-08 4:02 ` David Edelsohn 2003-03-08 11:57 ` Jan Hubicka @ 2003-03-08 13:34 ` Jan Hubicka 2003-03-08 16:06 ` David Edelsohn 2003-03-08 16:28 ` David Edelsohn 1 sibling, 2 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-08 13:34 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, gcc-patches > >>>>> Jan Hubicka writes: > > Jan> This is very puzzling.. from where the result_decl_comes from? > Jan> Can you please check the p1 and p2 in eq_node? > Jan> It seems to be that DECL_ASSEMBLER_NAME must have been executed for both > Jan> of them already when they were inserted into the table, so I really > Jan> don't understand why they are checked again... > > Optimization may have been confusing the information. I > recompiled cgraph.c without optimization. > > p1 is the cgraph_hash entry for the hash value provided. > > #4 0x10309fd0 in eq_node (p1=0x20133988, p2=0x305dd200) > at /gcc/dje/src/gcc/cgraph.c:75 > 75 return ((DECL_ASSEMBLER_NAME (((struct cgraph_node *) > p1)->decl)) == > (gdb) print ((struct cgraph_node *) p1)->decl > $9 = 0x30292600 > (gdb) pt > <pointer_type 30292600 > type <record_type 30292580 binary_function<typename Hi, I am attaching patch for the GC bits. I've also added sanity check, so hope it will trigger something. Can you please try it? In case it won't, can you please try to figure out from where the pointer type comes? Hope it will help, Honza Index: Makefile.in =================================================================== RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v retrieving revision 1.1011 diff -c -3 -p -r1.1011 Makefile.in *** Makefile.in 7 Mar 2003 01:20:51 -0000 1.1011 --- Makefile.in 8 Mar 2003 13:32:25 -0000 *************** simplify-rtx.o : simplify-rtx.c $(CONFIG *** 1539,1545 **** $(REGS_H) hard-reg-set.h flags.h real.h insn-config.h $(RECOG_H) $(EXPR_H) toplev.h \ output.h function.h $(GGC_H) $(OBSTACK_H) $(TM_P_H) $(TREE_H) $(TARGET_H) cgraph.o : cgraph.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ ! langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h cgraphunit.o : cgraphunit.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(REGS_H) \ --- 1539,1545 ---- $(REGS_H) hard-reg-set.h flags.h real.h insn-config.h $(RECOG_H) $(EXPR_H) toplev.h \ output.h function.h $(GGC_H) $(OBSTACK_H) $(TM_P_H) $(TREE_H) $(TARGET_H) cgraph.o : cgraph.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ ! langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h gt-cgraph.h cgraphunit.o : cgraphunit.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(REGS_H) \ *************** GTFILES = $(srcdir)/location.h $(srcdir) *** 1937,1943 **** $(srcdir)/profile.c $(srcdir)/ra-build.c $(srcdir)/regclass.c \ $(srcdir)/reg-stack.c \ $(srcdir)/sdbout.c $(srcdir)/stmt.c $(srcdir)/stor-layout.c \ ! $(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c \ $(out_file) \ @all_gtfiles@ --- 1937,1943 ---- $(srcdir)/profile.c $(srcdir)/ra-build.c $(srcdir)/regclass.c \ $(srcdir)/reg-stack.c \ $(srcdir)/sdbout.c $(srcdir)/stmt.c $(srcdir)/stor-layout.c \ ! $(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c $(srcdir)/cgraph.c \ $(out_file) \ @all_gtfiles@ *************** GTFILES_FILES_FILES = @all_gtfiles_files *** 1946,1952 **** GTFILES_LANG_DIR_NAMES = @subdirs@ GTFILES_SRCDIR = @srcdir@ ! gtype-desc.h gtype-desc.c gt-except.h gt-function.h : s-gtype; @true gt-integrate.h gt-stmt.h gt-tree.h gt-varasm.h gt-emit-rtl.h : s-gtype; @true gt-explow.h gt-stor-layout.h gt-regclass.h gt-lists.h : s-gtype; @true gt-alias.h gt-cselib.h gt-fold-const.h gt-gcse.h gt-profile.h : s-gtype; @true --- 1946,1952 ---- GTFILES_LANG_DIR_NAMES = @subdirs@ GTFILES_SRCDIR = @srcdir@ ! gt-cgraph.h gtype-desc.h gtype-desc.c gt-except.h gt-function.h : s-gtype; @true gt-integrate.h gt-stmt.h gt-tree.h gt-varasm.h gt-emit-rtl.h : s-gtype; @true gt-explow.h gt-stor-layout.h gt-regclass.h gt-lists.h : s-gtype; @true gt-alias.h gt-cselib.h gt-fold-const.h gt-gcse.h gt-profile.h : s-gtype; @true Index: cgraph.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cgraph.c,v retrieving revision 1.8 diff -c -3 -p -r1.8 cgraph.c *** cgraph.c 8 Mar 2003 13:26:35 -0000 1.8 --- cgraph.c 8 Mar 2003 13:32:25 -0000 *************** Software Foundation, 59 Temple Place - S *** 33,38 **** --- 33,46 ---- #include "debug.h" #include "target.h" #include "cgraph.h" + #include "varray.h" + + /* The declarations we know about must not get garbage collected. + We do not want callgraph datastructure to be saved via PCH code + since it would make it dificult to extend it into untramodule + optimizer later, so we store the references into the array to avoid + garbage collector from doing it's job. */ + static GTY(()) varray_type known_fns; /* Hash table used to convert declarations into nodes. */ static htab_t cgraph_hash = 0; *************** cgraph_node (decl) *** 82,89 **** struct cgraph_node *node; struct cgraph_node **slot; if (!cgraph_hash) ! cgraph_hash = htab_create (10, hash_node, eq_node, NULL); slot = (struct cgraph_node **) htab_find_slot_with_hash (cgraph_hash, decl, --- 90,103 ---- struct cgraph_node *node; struct cgraph_node **slot; + if (TREE_CODE (decl) != FUNCTION_DECL) + abort (); + if (!cgraph_hash) ! { ! cgraph_hash = htab_create (10, hash_node, eq_node, NULL); ! VARRAY_TREE_INIT (known_fns, 32, "known_fns"); ! } slot = (struct cgraph_node **) htab_find_slot_with_hash (cgraph_hash, decl, *************** cgraph_node (decl) *** 107,112 **** --- 121,127 ---- node->next_nested = node->origin->nested; node->origin->nested = node; } + VARRAY_PUSH_TREE (known_fns, decl); return node; } *************** dump_cgraph (f) *** 290,292 **** --- 305,309 ---- fprintf (f, "\n"); } } + + #include "gt-cgraph.h" ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-08 13:34 ` Jan Hubicka @ 2003-03-08 16:06 ` David Edelsohn 2003-03-08 16:28 ` David Edelsohn 1 sibling, 0 replies; 28+ messages in thread From: David Edelsohn @ 2003-03-08 16:06 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches I will try with the patch, but how can I disable this rtl_info feature without rolling back your cgraph patch. I need to be able to continue bootstrapping. Thanks, David ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Checking failure building arm-elf 2003-03-08 13:34 ` Jan Hubicka 2003-03-08 16:06 ` David Edelsohn @ 2003-03-08 16:28 ` David Edelsohn 2003-03-08 17:29 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) Jan Hubicka 1 sibling, 1 reply; 28+ messages in thread From: David Edelsohn @ 2003-03-08 16:28 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches With your patch to add the decls to varray, the failure no logner occurs. If I comment out the new VARRAY_PUSH_TREE (known_fns, decl); call, the failure re-appears. This makes a very strong case that it is a GC problem. David ^ permalink raw reply [flat|nested] 28+ messages in thread
* Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) 2003-03-08 16:28 ` David Edelsohn @ 2003-03-08 17:29 ` Jan Hubicka 2003-03-08 17:40 ` Fix for AIX bootstrap failure Andreas Jaeger ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Jan Hubicka @ 2003-03-08 17:29 UTC (permalink / raw) To: David Edelsohn; +Cc: Jan Hubicka, gcc-patches > With your patch to add the decls to varray, the failure no logner > occurs. If I comment out the new > > VARRAY_PUSH_TREE (known_fns, decl); > > call, the failure re-appears. This makes a very strong case that it is a > GC problem. Thanks. I wonder why this does not happen on i386 at all, but anyway it is incorrect to keep pointers into local decls without preventing them from being garbage collected. OK for mainline? Honza Sat Mar 8 18:27:10 CET 2003 Jan Hubicka <jh@suse.cz> * Makefile.in (cgraph.o): Depend on gt-cgraph.h and varray.h gt-cgraph.h: New GC file. * cgraph.c (known_fns): New static variable. (cgraph_node): Add the decl into varray. Index: Makefile.in =================================================================== RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v retrieving revision 1.1011 diff -c -3 -p -r1.1011 Makefile.in *** Makefile.in 7 Mar 2003 01:20:51 -0000 1.1011 --- Makefile.in 8 Mar 2003 17:26:44 -0000 *************** simplify-rtx.o : simplify-rtx.c $(CONFIG *** 1539,1545 **** $(REGS_H) hard-reg-set.h flags.h real.h insn-config.h $(RECOG_H) $(EXPR_H) toplev.h \ output.h function.h $(GGC_H) $(OBSTACK_H) $(TM_P_H) $(TREE_H) $(TARGET_H) cgraph.o : cgraph.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ ! langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h cgraphunit.o : cgraphunit.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(REGS_H) \ --- 1539,1545 ---- $(REGS_H) hard-reg-set.h flags.h real.h insn-config.h $(RECOG_H) $(EXPR_H) toplev.h \ output.h function.h $(GGC_H) $(OBSTACK_H) $(TM_P_H) $(TREE_H) $(TARGET_H) cgraph.o : cgraph.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) varray.h \ ! langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h gt-cgraph.h cgraphunit.o : cgraphunit.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ langhooks.h tree-inline.h toplev.h flags.h ggc.h $(TARGET_H) cgraph.h cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(REGS_H) \ *************** GTFILES = $(srcdir)/location.h $(srcdir) *** 1937,1943 **** $(srcdir)/profile.c $(srcdir)/ra-build.c $(srcdir)/regclass.c \ $(srcdir)/reg-stack.c \ $(srcdir)/sdbout.c $(srcdir)/stmt.c $(srcdir)/stor-layout.c \ ! $(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c \ $(out_file) \ @all_gtfiles@ --- 1937,1943 ---- $(srcdir)/profile.c $(srcdir)/ra-build.c $(srcdir)/regclass.c \ $(srcdir)/reg-stack.c \ $(srcdir)/sdbout.c $(srcdir)/stmt.c $(srcdir)/stor-layout.c \ ! $(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c $(srcdir)/cgraph.c \ $(out_file) \ @all_gtfiles@ *************** GTFILES_FILES_FILES = @all_gtfiles_files *** 1946,1952 **** GTFILES_LANG_DIR_NAMES = @subdirs@ GTFILES_SRCDIR = @srcdir@ ! gtype-desc.h gtype-desc.c gt-except.h gt-function.h : s-gtype; @true gt-integrate.h gt-stmt.h gt-tree.h gt-varasm.h gt-emit-rtl.h : s-gtype; @true gt-explow.h gt-stor-layout.h gt-regclass.h gt-lists.h : s-gtype; @true gt-alias.h gt-cselib.h gt-fold-const.h gt-gcse.h gt-profile.h : s-gtype; @true --- 1946,1952 ---- GTFILES_LANG_DIR_NAMES = @subdirs@ GTFILES_SRCDIR = @srcdir@ ! gt-cgraph.h gtype-desc.h gtype-desc.c gt-except.h gt-function.h : s-gtype; @true gt-integrate.h gt-stmt.h gt-tree.h gt-varasm.h gt-emit-rtl.h : s-gtype; @true gt-explow.h gt-stor-layout.h gt-regclass.h gt-lists.h : s-gtype; @true gt-alias.h gt-cselib.h gt-fold-const.h gt-gcse.h gt-profile.h : s-gtype; @true Index: cgraph.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cgraph.c,v retrieving revision 1.8 diff -c -3 -p -r1.8 cgraph.c *** cgraph.c 8 Mar 2003 13:26:35 -0000 1.8 --- cgraph.c 8 Mar 2003 17:26:44 -0000 *************** Software Foundation, 59 Temple Place - S *** 33,38 **** --- 33,46 ---- #include "debug.h" #include "target.h" #include "cgraph.h" + #include "varray.h" + + /* The declarations we know about must not get garbage collected. + We do not want callgraph datastructure to be saved via PCH code + since it would make it dificult to extend it into untramodule + optimizer later, so we store the references into the array to avoid + garbage collector from doing it's job. */ + static GTY(()) varray_type known_fns; /* Hash table used to convert declarations into nodes. */ static htab_t cgraph_hash = 0; *************** cgraph_node (decl) *** 82,89 **** struct cgraph_node *node; struct cgraph_node **slot; if (!cgraph_hash) ! cgraph_hash = htab_create (10, hash_node, eq_node, NULL); slot = (struct cgraph_node **) htab_find_slot_with_hash (cgraph_hash, decl, --- 90,103 ---- struct cgraph_node *node; struct cgraph_node **slot; + if (TREE_CODE (decl) != FUNCTION_DECL) + abort (); + if (!cgraph_hash) ! { ! cgraph_hash = htab_create (10, hash_node, eq_node, NULL); ! VARRAY_TREE_INIT (known_fns, 32, "known_fns"); ! } slot = (struct cgraph_node **) htab_find_slot_with_hash (cgraph_hash, decl, *************** cgraph_node (decl) *** 107,112 **** --- 121,127 ---- node->next_nested = node->origin->nested; node->origin->nested = node; } + VARRAY_PUSH_TREE (known_fns, decl); return node; } *************** dump_cgraph (f) *** 290,292 **** --- 305,309 ---- fprintf (f, "\n"); } } + + #include "gt-cgraph.h" ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure 2003-03-08 17:29 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) Jan Hubicka @ 2003-03-08 17:40 ` Andreas Jaeger 2003-03-08 18:11 ` Zack Weinberg 2003-03-08 19:46 ` Andreas Jaeger 2003-03-08 22:32 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) David Edelsohn 2003-03-10 20:41 ` Mike Stump 2 siblings, 2 replies; 28+ messages in thread From: Andreas Jaeger @ 2003-03-08 17:40 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, gcc-patches Jan Hubicka <jh@suse.cz> writes: >> With your patch to add the decls to varray, the failure no logner >> occurs. If I comment out the new >> >> VARRAY_PUSH_TREE (known_fns, decl); >> >> call, the failure re-appears. This makes a very strong case that it is a >> GC problem. > > Thanks. I wonder why this does not happen on i386 at all, but anyway > it is incorrect to keep pointers into local decls without preventing > them from being garbage collected. > > OK for mainline? > > Honza > > Sat Mar 8 18:27:10 CET 2003 Jan Hubicka <jh@suse.cz> > * Makefile.in (cgraph.o): Depend on gt-cgraph.h and varray.h A point at the end. > gt-cgraph.h: New GC file. I guess this should be: * gt-cgraph.h: New GC file. > [...] > *************** GTFILES = $(srcdir)/location.h $(srcdir) > *** 1937,1943 **** > $(srcdir)/profile.c $(srcdir)/ra-build.c $(srcdir)/regclass.c \ > $(srcdir)/reg-stack.c \ > $(srcdir)/sdbout.c $(srcdir)/stmt.c $(srcdir)/stor-layout.c \ > ! $(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c \ > $(out_file) \ > @all_gtfiles@ > > --- 1937,1943 ---- > $(srcdir)/profile.c $(srcdir)/ra-build.c $(srcdir)/regclass.c \ > $(srcdir)/reg-stack.c \ > $(srcdir)/sdbout.c $(srcdir)/stmt.c $(srcdir)/stor-layout.c \ > ! $(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c $(srcdir)/cgraph.c \ It looks as if these files are sorted. Can you resort the list, please? > + #include "varray.h" > + > + /* The declarations we know about must not get garbage collected. > + We do not want callgraph datastructure to be saved via PCH code > + since it would make it dificult to extend it into untramodule > + optimizer later, so we store the references into the array to avoid > + garbage collector from doing it's job. */ I suggest: /* The known declarations must not get garbage collected. Callgraph datastructures should not get saved via PCH code since this would make it difficult to extend into intra-module optimizer later. So we store only the references into the array to avoid the garbage collector from doing its job. */ Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure 2003-03-08 17:40 ` Fix for AIX bootstrap failure Andreas Jaeger @ 2003-03-08 18:11 ` Zack Weinberg 2003-03-08 18:18 ` Jan Hubicka 2003-03-08 19:46 ` Andreas Jaeger 1 sibling, 1 reply; 28+ messages in thread From: Zack Weinberg @ 2003-03-08 18:11 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Jan Hubicka, David Edelsohn, gcc-patches Andreas Jaeger <aj@suse.de> writes: > Jan Hubicka <jh@suse.cz> writes: > >> Thanks. I wonder why this does not happen on i386 at all, but anyway >> it is incorrect to keep pointers into local decls without preventing >> them from being garbage collected. >> >> OK for mainline? Yes, if you make Andreas's suggested changes, and: > I suggest: > > /* The known declarations must not get garbage collected. Callgraph > datastructures should not get saved via PCH code since this would > make it difficult to extend into intra-module optimizer later. So > we store only the references into the array to avoid the garbage > collector from doing its job. */ This is still not grammatical English; you can't use 'avoid' like that, and 'doing its job' implies functioning correctly, which it isn't. "to prevent the garbage collector from deleting live data" is better. I don't understand what you're trying to say, though. Why is it undesirable to preserve the (partial) call graph in a pch dump? zw ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure 2003-03-08 18:11 ` Zack Weinberg @ 2003-03-08 18:18 ` Jan Hubicka 2003-03-08 18:55 ` Zack Weinberg 0 siblings, 1 reply; 28+ messages in thread From: Jan Hubicka @ 2003-03-08 18:18 UTC (permalink / raw) To: Zack Weinberg; +Cc: Andreas Jaeger, Jan Hubicka, David Edelsohn, gcc-patches > Andreas Jaeger <aj@suse.de> writes: > > > Jan Hubicka <jh@suse.cz> writes: > > > >> Thanks. I wonder why this does not happen on i386 at all, but anyway > >> it is incorrect to keep pointers into local decls without preventing > >> them from being garbage collected. > >> > >> OK for mainline? > > Yes, if you make Andreas's suggested changes, and: > > > I suggest: > > > > /* The known declarations must not get garbage collected. Callgraph > > datastructures should not get saved via PCH code since this would > > make it difficult to extend into intra-module optimizer later. So > > we store only the references into the array to avoid the garbage > > collector from doing its job. */ > > This is still not grammatical English; you can't use 'avoid' like > that, and 'doing its job' implies functioning correctly, which it > isn't. "to prevent the garbage collector from deleting live data" is > better. > > I don't understand what you're trying to say, though. Why is it > undesirable to preserve the (partial) call graph in a pch dump? Because in the case we will use PCH code to preserve trees for whole program compilation, we want to save the callgraph and local function information separately, so we can fetch it first, propagate global infromation and then use PCH code to load function bodies as needed. Honza > > zw ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure 2003-03-08 18:18 ` Jan Hubicka @ 2003-03-08 18:55 ` Zack Weinberg 0 siblings, 0 replies; 28+ messages in thread From: Zack Weinberg @ 2003-03-08 18:55 UTC (permalink / raw) To: Jan Hubicka; +Cc: Andreas Jaeger, David Edelsohn, gcc-patches Jan Hubicka <jh@suse.cz> writes: >> I don't understand what you're trying to say, though. Why is it >> undesirable to preserve the (partial) call graph in a pch dump? > > Because in the case we will use PCH code to preserve trees for whole > program compilation, we want to save the callgraph and local function > information separately, so we can fetch it first, propagate global > infromation and then use PCH code to load function bodies as needed. I'm still not getting it, but I think you'd have to explain the entire of cgraph.c to me. It would be better if I just go read the code and then bug you if I'm still confused. Go ahead and check in your patch (with the grammar fixes etc) zw ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure 2003-03-08 17:40 ` Fix for AIX bootstrap failure Andreas Jaeger 2003-03-08 18:11 ` Zack Weinberg @ 2003-03-08 19:46 ` Andreas Jaeger 1 sibling, 0 replies; 28+ messages in thread From: Andreas Jaeger @ 2003-03-08 19:46 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, gcc-patches Andreas Jaeger <aj@suse.de> writes: > Jan Hubicka <jh@suse.cz> writes: > [...] >> Sat Mar 8 18:27:10 CET 2003 Jan Hubicka <jh@suse.cz> >> * Makefile.in (cgraph.o): Depend on gt-cgraph.h and varray.h > > A point at the end. >> gt-cgraph.h: New GC file. > > I guess this should be: > * gt-cgraph.h: New GC file. No, I'm wrong - it is really part of Makefile.in, so it should be: (gt-cgraph.h): New GC file. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) 2003-03-08 17:29 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) Jan Hubicka 2003-03-08 17:40 ` Fix for AIX bootstrap failure Andreas Jaeger @ 2003-03-08 22:32 ` David Edelsohn 2003-03-08 22:55 ` Hans-Peter Nilsson 2003-03-10 20:41 ` Mike Stump 2 siblings, 1 reply; 28+ messages in thread From: David Edelsohn @ 2003-03-08 22:32 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc-patches >>>>> Jan Hubicka writes: Jan> Thanks. I wonder why this does not happen on i386 at all, but anyway Jan> it is incorrect to keep pointers into local decls without preventing Jan> them from being garbage collected. Thanks for helping track down the problem. AIX process address spaces use much different ranges than GNU/Linux and cgraph is hashing pointers, so it is likely that running on AIX tests a very different hashtable layout. David ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) 2003-03-08 22:32 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) David Edelsohn @ 2003-03-08 22:55 ` Hans-Peter Nilsson 0 siblings, 0 replies; 28+ messages in thread From: Hans-Peter Nilsson @ 2003-03-08 22:55 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, gcc-patches On Sat, 8 Mar 2003, David Edelsohn wrote: > >>>>> Jan Hubicka writes: > > Jan> Thanks. I wonder why this does not happen on i386 at all, but anyway > Jan> it is incorrect to keep pointers into local decls without preventing > Jan> them from being garbage collected. > > Thanks for helping track down the problem. > > AIX process address spaces use much different ranges than > GNU/Linux and cgraph is hashing pointers, so it is likely that running on > AIX tests a very different hashtable layout. Pretty please make it stop hashing pointers! Do I need to mention that it just causes hard to find bugs and mysterious host-dependent code differences? ;-) If this isn't likely to happen soon (as part of some other rewrite, perhaps?) please tell, and I can cook up a patch. brgds, H-P ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) 2003-03-08 17:29 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) Jan Hubicka 2003-03-08 17:40 ` Fix for AIX bootstrap failure Andreas Jaeger 2003-03-08 22:32 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) David Edelsohn @ 2003-03-10 20:41 ` Mike Stump 2 siblings, 0 replies; 28+ messages in thread From: Mike Stump @ 2003-03-10 20:41 UTC (permalink / raw) To: Jan Hubicka; +Cc: David Edelsohn, gcc-patches On Saturday, March 8, 2003, at 09:29 AM, Jan Hubicka wrote: > + /* The declarations we know about must not get garbage collected. > + We do not want callgraph datastructure to be saved via PCH code > + since it would make it dificult to extend it into untramodule What does untramodule mean? :-) > + optimizer later, so we store the references into the array to > avoid > + garbage collector from doing it's job. */ ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2003-03-10 20:41 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-06 11:22 Checking failure building arm-elf Richard Earnshaw 2003-03-06 12:25 ` Andreas Schwab 2003-03-06 13:12 ` Jan Hubicka 2003-03-06 13:12 ` Hans-Peter Nilsson 2003-03-06 13:31 ` Jan Hubicka 2003-03-06 14:29 ` Hans-Peter Nilsson 2003-03-07 2:44 ` David Edelsohn 2003-03-08 13:05 ` Jan Hubicka 2003-03-07 3:04 ` David Edelsohn 2003-03-07 11:30 ` Jan Hubicka 2003-03-07 16:45 ` David Edelsohn 2003-03-07 16:55 ` Jan Hubicka 2003-03-07 16:50 ` David Edelsohn 2003-03-07 22:39 ` Jan Hubicka 2003-03-08 4:02 ` David Edelsohn 2003-03-08 11:57 ` Jan Hubicka 2003-03-08 13:34 ` Jan Hubicka 2003-03-08 16:06 ` David Edelsohn 2003-03-08 16:28 ` David Edelsohn 2003-03-08 17:29 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) Jan Hubicka 2003-03-08 17:40 ` Fix for AIX bootstrap failure Andreas Jaeger 2003-03-08 18:11 ` Zack Weinberg 2003-03-08 18:18 ` Jan Hubicka 2003-03-08 18:55 ` Zack Weinberg 2003-03-08 19:46 ` Andreas Jaeger 2003-03-08 22:32 ` Fix for AIX bootstrap failure (Was Re: Checking failure building arm-elf) David Edelsohn 2003-03-08 22:55 ` Hans-Peter Nilsson 2003-03-10 20:41 ` Mike Stump
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).