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