gcc-2.95: asm-extn1.C regression

[Jeffrey A Law <law at cygnus dot com>]

This looks like a bug in the C++ front-end.  Given this testcase on a sparc:



extern void traptable(void);

main()
{
  asm("wr    %0,%%tbr" : : "r" (traptable));
}

We abort in emit_move_insn because we have mis-matched modes.  The mis-matched
modes appear to be due to a bogus tree expression passed to the generic
asm code.

If I put a breakpoint in finish_asm_statement, then examine "input_operands"
I get:

 <tree_list 0x83276f0 allocated from function obstack
   
    purpose <string_cst 0x83284d4
        type <array_type 0x8334648 type <integer_type 0x8331670 char>
            allocated from permanent_obstack
            permanent BLK
            size <integer_cst 0x83346e4 constant permanent 1608>
            align 8 symtab 0 alias set -1 domain <integer_type 0x83345b0>>
        allocated from momentary_obstack
        constant "r">
    value <function_decl 0x8343d54 traptable
        type <function_type 0x8334bb4 type <void_type 0x83342bc void>
            allocated from permanent_obstack
            permanent DI
            size <integer_cst 0x8330420 constant permanent 64>
            align 64 symtab 0 alias set -1
            arg-types <tree_list 0x8334394 allocated from permanent_obstack
                unsigned permanent value <void_type 0x83342bc void>>>
        allocated from permanent_obstack
        used permanent public external decl_2 SI file foo.c line 1
       
        decl-main-variant 0x8343d54
        (mem/f:SI (symbol_ref:SI ("traptable__Fv")) 0)
        chain <var_decl 0x833c8dc __func__ type <array_type 0x8334648>
            allocated from permanent_obstack
            readonly asm_written permanent static ignored in_system_header BLK 
file <internal> line 0 size <integer_cst 0x83346e4 1608>
            align 8 initial <string_cst 0x833c940>
            (mem/s/u:BLK (symbol_ref:SI ("__func__")) 0) chain <var_decl 
0x833c80c __PRETTY_FUNCTION__>>>>
$

Of particular interest is the TREE_VALUE field, which is a raw FUNCTION_DECL.
I believe we should have had an ADDR_EXPR containing the FUNCTION_DECL.

If you run the same testcase under the C front-end, that's precisely what
happens.  We have an ADDR_EXPR (FUNCTION_DECL) and everything is happy.

Similarly if the testcase is slightly modified by putting an addressof
operator on the reference to traptable in the asm statement the C++ front-end
will correctly wrap the FUNCTION_DECL inside an ADDR_EXPR.

Can one of you take a looksie?

jeff