Re: Bootstrap error on arm-netbsd1.4 (release branch)

[Richard Earnshaw <rearnsha at arm dot com>]

> I'd suggest a breakpoint in make_call_insn_raw conditional on 
> cur_insn_uid == 5
> 
> Then walk backwards from that point to see who/what is setting the weird
> mode on the return register from the call.
> 
> I would also verify that the stage1 compiler exhibits this bug...  It may be
> the case that the compiler is mis-compiling itself...

I'm fairly sure it's not a self-compilation problem.  As I said in the 
previous mail, the dump was from a sparc-solaris->arm-netbsd cross (a bit 
faster to build and a more stable implementation of gdb :-( ).

Anyway, the tree node this is created from looks somewhat odd; at the call 
to emit_call_1 we have:

emit_call_1 (funexp=0x21f138, fndecl=0x21f0d0, funtype=0x20c148, 
    stack_size=0, rounded_stack_size=0, struct_value_size=0, 
    next_arg_reg=0x207c40, valreg=0x207c30, old_inhibit_defer_pop=0, 
    call_fusage=0x0, is_const=0)

where:

funexp = (symbol_ref:SI ("foo"))

fndecl =  <function_decl 21f0d0 foo
    type <function_type 20c148
        type <void_type 20ac70 void allocated from permanent_obstack
            permanent string-flag needs-constructing transparent-union 
type_0 type_2 type_3 type_6 CC_NOOV
            size <integer_cst 20ac40 constant permanent 0>
            align 8 symtab 0 alias set -1
            pointer_to_this <pointer_type 20ad50>>
        allocated from permanent_obstack
        permanent DI
        size <integer_cst 204cb8 constant permanent 64>
        align 32 symtab 0 alias set 0
        arg-types <tree_list 20b2b0 allocated from permanent_obstack
            permanent value <void_type 20ac70 void>>
        pointer_to_this <pointer_type 21f6b8>>
    allocated from permanent_obstack
    addressable asm_written used permanent static SI file ch2.c line 4
   
    result <result_decl 21f348 type <void_type 20ac70 void>
        allocated from permanent_obstack
        permanent VOID file ch2.c line 4 size <integer_cst 20ac40 0>
        align 8 context <function_decl 21f0d0 foo>> initial <error_mark 
209a78>
    (mem/f:SI (symbol_ref:SI ("foo")) 0) chain <var_decl 20f870 __func__>>

funtype =  <function_type 20c148
    type <void_type 20ac70 void allocated from permanent_obstack
        permanent string-flag needs-constructing transparent-union type_0 
type_2 type_3 type_6 CC_NOOV
        size <integer_cst 20ac40 constant permanent 0>
        align 8 symtab 0 alias set -1
        pointer_to_this <pointer_type 20ad50>>
    allocated from permanent_obstack
    permanent DI
    size <integer_cst 204cb8 type <integer_type 204c28 unsigned int> 
constant permanent 64>
    align 32 symtab 0 alias set 0
    arg-types <tree_list 20b2b0 allocated from permanent_obstack
        permanent value <void_type 20ac70 void>>
    pointer_to_this <pointer_type 21f6b8>>

next_arg_reg = (reg 0 r0)

Note that both fndecl & funtype have that rather strange type entry:

        type <void_type 20ac70 void allocated from permanent_obstack
            permanent string-flag needs-constructing transparent-union 
type_0 type_2 type_3 type_6 CC_NOOV

This magically appears during grokdeclarator in the loop which reads

	  /* Set the TYPE_CONTEXTs for each tagged type which is local to
	     the formal parameter list of this FUNCTION_TYPE to point to
	     the FUNCTION_TYPE node itself.  */

	  {
	    register tree link;

	    for (link = last_function_parm_tags;
		 link;
		 link = TREE_CHAIN (link))
	      TYPE_CONTEXT (TREE_VALUE (link)) = type;


After this I'm completely lost in the TREEs :-(

I can't be sure, but my guess would be that we have some tree information 
that wasn't on the correct obstack and has been corrupted by the time we 
are compiling the constructor stub.

Another thing to note:  the function foo was declared "void", yet the 
compiler is still using gen_call_value to generate an insn for it; it 
should be using gen_call.

Richard.