m68k-*-*bsd `Internal compiler error' mostly tracked down

[Jeffrey A Law]

  In message <199802262305.AAA00949@quatramaran.ens.fr>you write:
  > I've got much more complete information regarding my bug.
  > As already stated, it seems to affect only the m68k-*-*bsd based systems.
  > 
  > The turn point is a patch to g++:
  > 
  > Thu Dec 18 14:43:19 1997  Jason Merrill  <jason@yorick.cygnus.com>
  > 
  > 	* cp-tree.def: Add AGGR_INIT_EXPR.
  > 	* error.c, tree.c, typeck.c: Replace uses of NEW_EXPR with
  > 	AGGR_INIT_EXPR where appropriate.
  > 	* expr.c (cplus_expand_expr): Likewise.  Simplify.
  > 
  > 	* decl2.c (finish_file): Remove call to register_exception_table.
  > 
  > where the decl2.c part is unrelated to the other patch.
  > 
  > Before that point in time, libstdc++ compiles correctly. After that point,
  > g++ turns up belly-up while compiling the complex numbers support.
It appears that we're dereferencing a dangling pointer in the tree structure.

A few frames up from the error:

(gdb) p debug_tree(exp1)
 <nop_expr 40027f38
    type <reference_type 400515a8
        type <record_type 400514f8 complex<float> allocated from permanent_obstack
            readonly permanent needs-constructing type_1 type_5 DIdecl 400519c0 real>
                elt 5 <function_decl 40051bc8 imag>>
            pointer_to_this <pointer_type 40051550> reference_to_this <reference_type 400515a8>>
        allocated from permanent_obstack
        unsigned permanent SI
        size <integer_cst 40030c28 constant permanent 32>
        align 16 symtab 0>
    allocated from momentary_obstack

    arg 0 <nop_expr 40027f20
        type <pointer_type 40051550 type <record_type 400514f8 complex<float>>
            allocated from permanent_obstack
            unsigned permanent SI size <integer_cst 40030c28 32>
            align 16 symtab 0>
        allocated from momentary_obstack
       
        arg 0 <convert_expr 40027f08 type <pointer_type 4004df50>
            allocated from momentary_obstack
            arg 0 <var_decl 40058c50>>>>

Note carefully "arg0"; it's on the momentary obstack.  If we do a print_tree
on it we get:

 <nop_expr 40027f20
    type <pointer_type 40051550
        type <record_type 400514f8 complex<float> allocated from permanent_obstack
            readonly permanent needs-constructing type_1 type_5 DI
            size <integer_cst 40052a10 constant permanent 64>
            align 16 symtab 0 fields <field_decl 40051d80 re>
           needs-constructor X() X(constX&) has= this=(X&) n_parents 0 n_ancestors 0 use_template=2
            member-functions <tree_vec 400399c8 not allocated from any obstack
               
                elt 0 <function_decl 40051318 complex>
                elt 2 <function_decl 40052878 __as>
                elt 3 <function_decl 40051740 __apl>
                elt 4 <function_decl 400519c0 real>
                elt 5 <function_decl 40051bc8 imag>>
            pointer_to_this <pointer_type 40051550> reference_to_this <reference_type 400515a8>>
        allocated from permanent_obstack
        unsigned permanent SI
        size <integer_cst 40030c28 constant permanent 32>
        align 16 symtab 0>
    allocated from momentary_obstack
   
    arg 0 <convert_expr 40027f08
        type <pointer_type 4004df50 type <record_type 4004de10 complex<float>>
            allocated from permanent_obstack
            unsigned permanent SI size <integer_cst 40030c28 32>
            align 16 symtab 0>
        allocated from momentary_obstack
       
        arg 0 <var_decl 40058c50 type <reference_type 400514a0>
            allocated from function maybepermanent obstack
            unsigned used SI file j.C line 52 size <integer_cst 40030c28 32>
            align 16
            
Program received signal SIGSEGV, Segmentation fault.



This is out of my league, I don't do much/any front-end work.  Someone
(Jason?) will have to investigate further.

Marc Espie's testcase dies on a m68k-hp-netbsd targeted cross compiler,
for me.  If anyone needs the testcase, I've still got a copy.

jeff