public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* 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-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 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: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 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-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-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).