Re: mainline bootstrap failure on i686-pc-linux-gnu

["Zack Weinberg" <zackw at stanford dot edu>]

On Tue, May 01, 2001 at 11:07:19AM -0700, Matt Kraai wrote:
> Howdy,
> 
> When bootstrapping from CVS, I receive the following error:
...
> /home/kraai/dev/gcc/libjava/resolve.cc: In function `_Jv_word 
>    _Jv_ResolvePoolEntry(java::lang::Class*, int)':
> /home/kraai/dev/gcc/libjava/resolve.cc:134: Internal compiler error in 
>    c_expand_expr, at c-common.c:4271
> Please submit a full bug report, with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

I see this also.

(gdb) bt 
#0  debug_tree (node=0x404d7120) at ../../../gcc_no-POSIX/gcc/print-tree.c:49
#1  0x8139e2c in c_expand_expr (exp=0x404d7120, target=0x404ecca0, 
    tmode=SImode, modifier=EXPAND_NORMAL)
    at ../../../gcc_no-POSIX/gcc/c-common.c:4271
#2  0x81a2903 in expand_expr (exp=0x404d7120, target=0x404ecca0, tmode=SImode, 
    modifier=EXPAND_NORMAL) at ../../../gcc_no-POSIX/gcc/expr.c:8804
#3  0x8194466 in store_expr (exp=0x404d7120, target=0x404ecca0, want_value=0)
    at ../../../gcc_no-POSIX/gcc/expr.c:4147
#4  0x819bc2b in expand_expr (exp=0x404d7140, target=0x404ecca0, 
    tmode=VOIDmode, modifier=EXPAND_NORMAL)
    at ../../../gcc_no-POSIX/gcc/expr.c:8441
#5  0x819a14b in expand_expr (exp=0x404d7160, target=0x404ecc90, tmode=SImode, 
    modifier=EXPAND_NORMAL) at ../../../gcc_no-POSIX/gcc/expr.c:6965
#6  0x8194466 in store_expr (exp=0x404d7160, target=0x404ecc90, want_value=0)
    at ../../../gcc_no-POSIX/gcc/expr.c:4147
#7  0x81930cf in expand_assignment (to=0x404cec98, from=0x404d7160, 
    want_value=0, suggest_reg=0) at ../../../gcc_no-POSIX/gcc/expr.c:3962
#8  0x82d1ae8 in expand_decl_init (decl=0x404cec98)
    at ../../../gcc_no-POSIX/gcc/stmt.c:3925
#9  0x813fff9 in emit_local_var (decl=0x404cec98)
    at ../../../gcc_no-POSIX/gcc/c-semantics.c:275
#10 0x81417a9 in expand_stmt (t=0x404d6c94)
    at ../../../gcc_no-POSIX/gcc/c-semantics.c:729
#11 0x8141799 in expand_stmt (t=0x404cdc58)
    at ../../../gcc_no-POSIX/gcc/c-semantics.c:749
#12 0x8141799 in expand_stmt (t=0x404cdc44)
    at ../../../gcc_no-POSIX/gcc/c-semantics.c:749
#13 0x81411fe in genrtl_switch_stmt (t=0x404d15a0)
    at ../../../gcc_no-POSIX/gcc/c-semantics.c:599
#14 0x8141819 in expand_stmt (t=0x404cd5b4)
    at ../../../gcc_no-POSIX/gcc/c-semantics.c:761
#15 0x8141799 in expand_stmt (t=0x404cd5a0)
    at ../../../gcc_no-POSIX/gcc/c-semantics.c:749
#16 0x8116fc9 in expand_body (fn=0x402aaa28)
    at ../../../gcc_no-POSIX/gcc/cp/semantics.c:2467
#17 0x80d6ca3 in yyparse_1 () at /usr/share/bison/bison.simple:765
#18 0x82dd678 in compile_file (
    name=0xbffffb97 "../../../../gcc_no-POSIX/libjava/resolve.cc")
    at ../../../gcc_no-POSIX/gcc/toplev.c:2324
#19 0x82e19c9 in toplev_main (argc=98, argv=0xbffff204)
    at ../../../gcc_no-POSIX/gcc/toplev.c:4936
#20 0x4003b16b in __libc_start_main () from /lib/libc.so.6

I stuck the debug_tree call right before the abort in c_expand_expr.
The trouble is that expand_expr is getting called on an AGGR_INIT_EXPR
node; neither it, nor cplus_expand_expr, nor c_expand_expr knows how
to deal with that.  This is the expression:

 <aggr_init_expr 0x404d7120
    type <union_type 0x40284dd0 _Jv_word type_1 type_5 SI
        size <integer_cst 0x40164be0 constant 32>
        unit size <integer_cst 0x40164c00 constant 4>
        user align 32 symtab 392 alias set 0
        fields <field_decl 0x40304f08 o type <pointer_type 0x401bd2d8 jobject>
            unsigned nonlocal decl_3 SI file ../../../../gcc_no-POSIX/libjava/include/jvm.h line 51 size <integer_cst 0x40164be0 32> unit size <integer_cst 0x40164c00 4>
            align 32 offset_align 128
            offset <integer_cst 0x40164cc0 constant 0>
            bit offset <integer_cst 0x40164ce0 constant 0> context <union_type 0x40284dd0 _Jv_word> arguments <integer_cst 0x40164cc0 0> chain <field_decl 0x40304f70 i>>
        X() X(constX&) this=(X&)
        pointer_to_this <pointer_type 0x40284e38> reference_to_this <reference_type 0x40306af8> chain <type_decl 0x40284ea0 _Jv_word>>
    side-effects
    arg 0 <addr_expr 0x404d91f4
        type <pointer_type 0x404ced00 type <function_type 0x402aa9c0>
            unsigned SI size <integer_cst 0x40164be0 32> unit size <integer_cst 0x40164c00 4>
            align 32 symtab 0 alias set -1>
        constant
        arg 0 <function_decl 0x402aaa28 _Jv_ResolvePoolEntry type <function_type 0x402aa9c0>
            addressable used public static decl_5 QI file ../../../../gcc_no-POSIX/libjava/resolve.cc line 78 arguments <parm_decl 0x404ce1a0 klass> result <result_decl 0x404ce340> initial <block 0x404e77e0>
            chain <function_decl 0x402aa888 _Jv_InitField>>>
    arg 1 <tree_list 0x404d9258
        value <parm_decl 0x404ce1a0 klass type <pointer_type 0x401bd3a8 jclass>
            unsigned used SI file ../../../../gcc_no-POSIX/libjava/resolve.cc line 78 size <integer_cst 0x40164be0 32> unit size <integer_cst 0x40164c00 4>
            align 32 context <function_decl 0x402aaa28 _Jv_ResolvePoolEntry> initial <pointer_type 0x401bd3a8 jclass>
            (reg/v/f:SI 59) arg-type <pointer_type 0x401bd3a8 jclass>
            incoming-rtl (mem/f:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
        (const_int 4 [0x4])) 73) chain <parm_decl 0x404ce208 index>>
        chain <tree_list 0x404d92f8
            value <nop_expr 0x404d92e4 type <integer_type 0x40168340 int>
                arg 0 <var_decl 0x404ceb60 class_index>>>>
    arg 2 <var_decl 0x404ced68 type <union_type 0x40284dd0 _Jv_word>
        used SI file ../../../../gcc_no-POSIX/libjava/resolve.cc line 134 size <integer_cst 0x40164be0 32> unit size <integer_cst 0x40164c00 4>
        user align 32 context <function_decl 0x402aaa28 _Jv_ResolvePoolEntry>
        (reg:SI 103)>>

If I try to print out the containing expression, debug_tree
segfaults.  This may therefore be a memory corruption bug.

That's as far as I can get at the moment.

zw