------- 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
