------- Comment #3 from hubicka at gcc dot gnu dot org  2010-09-09 11:02 -------
Hmm, is it?
C equivalent IMO is:
int a(void);

typedef void (*ptr) (void);

static const ptr array[1]={(ptr)a};
ptr t;
main()
{
  t=array[0];
}

Here we have ctor represented as follows:
 <nop_expr 0x7ffff6b53f30
    type <pointer_type 0x7ffff6b383f0
        type <function_type 0x7ffff7eee690 type <void_type 0x7ffff7ed9e70 void>
            QI
            size <integer_cst 0x7ffff7ec54d8 constant 8>
            unit size <integer_cst 0x7ffff7ec5500 constant 1>
            align 8 symtab 0 alias set -1 canonical type 0x7ffff7eee690
            arg-types <tree_list 0x7ffff7ec5eb0 value <void_type 0x7ffff7ed9e70
void>>
            pointer_to_this <pointer_type 0x7ffff6b383f0>>
        unsigned DI
        size <integer_cst 0x7ffff7ec57d0 constant 64>
        unit size <integer_cst 0x7ffff7ec57f8 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0x7ffff6b383f0
        pointer_to_this <pointer_type 0x7ffff6b38738>>
    constant
    arg 0 <addr_expr 0x7ffff6b53f00
        type <pointer_type 0x7ffff6b38bd0 type <function_type 0x7ffff7eee888>
            unsigned DI size <integer_cst 0x7ffff7ec57d0 64> unit size
<integer_cst 0x7ffff7ec57f8 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff6b38bd0>
        constant
        arg 0 <function_decl 0x7ffff6b37f00 a type <function_type
0x7ffff7eee888>
            addressable used public external decl_5 QI file t.c line 1 col 5
align 8 chain <var_decl 0x7ffff6b550a0 t>>
        t.c:5:33>
    t.c:5:28>

this gets into canonicalize_constructor_val and it does STRIP_NOPS so we
return addr_expr with different type than array_ref from
fold_const_aggregate_ref (this code is copied from old implementation, the
STRIP_NOPS there seemed bid odd to me originally) and this lands in ccp_fold
that is happy and CCP re-inserts the nop later.

I guess C++ FE is wrong to produce type mismatch in addr_expr?  That should be
easy to fix.

I wonder about other users of fold_const_aggregate_ref. Shall they also work on
re-inserting the conversions to avoid possible type mismatch?

Obviously more worms...
Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605

Reply via email to