http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52611
--- Comment #3 from Steven Bosscher <steven at gcc dot gnu.org> 2012-03-18 16:21:54 UTC --- The problem happens very early on, during gimplification: #1 0x00000000009e7546 in verify_gimple_assign_unary (stmt=0x7ffff7fb5f00) at ../../gcc-4.6.3/gcc/tree-cfg.c:3241 3241 error ("invalid types in nop conversion"); (gdb) l 3236 3237 /* Otherwise assert we are converting between types of the 3238 same kind. */ 3239 if (INTEGRAL_TYPE_P (lhs_type) != INTEGRAL_TYPE_P (rhs1_type)) 3240 { 3241 error ("invalid types in nop conversion"); 3242 debug_generic_expr (lhs_type); 3243 debug_generic_expr (rhs1_type); 3244 return true; 3245 } (gdb) p debug_tree(lhs_type) <integer_type 0x7ffff7faa348 UINT64 unsigned DI size <integer_cst 0x7ffff7ec7a00 type <integer_type 0x7ffff7ee20a8 bit_size_type> constant 64> unit size <integer_cst 0x7ffff7ec7a28 type <integer_type 0x7ffff7ee2000 long unsigned int> constant 8> align 64 symtab 0 alias set -1 canonical type 0x7ffff7ee27e0 precision 64 min <integer_cst 0x7ffff7ec7a50 0> max <integer_cst 0x7ffff7ec79d8 18446744073709551615> context <translation_unit_decl 0x7ffff7eefda8 D.1262>> $7 = void (gdb) p debug_tree(rhs1_type) <pointer_type 0x7ffff7ee2f18 type <void_type 0x7ffff7ee2e70 void VOID align 8 symtab 0 alias set -1 canonical type 0x7ffff7ee2e70 pointer_to_this <pointer_type 0x7ffff7faa1f8>> public unsigned SI size <integer_cst 0x7ffff7ec7898 type <integer_type 0x7ffff7ee20a8 bit_size_type> constant 32> unit size <integer_cst 0x7ffff7ec75a0 type <integer_type 0x7ffff7ee2000 long unsigned int> constant 4> align 32 symtab 0 alias set -1 canonical type 0x7ffff7ee2f18 pointer_to_this <pointer_type 0x7ffff7ef8348> reference_to_this <reference_type 0x7ffff7ef6f18>> $8 = void (gdb) bt 10 #0 error (gmsgid=0xfe0890 "invalid types in nop conversion") at ../../gcc-4.6.3/gcc/diagnostic.c:751 #1 0x00000000009e7546 in verify_gimple_assign_unary (stmt=0x7ffff7fb5f00) at ../../gcc-4.6.3/gcc/tree-cfg.c:3241 #2 0x00000000009e9627 in verify_gimple_assign (stmt=0x7ffff7fb5f00) at ../../gcc-4.6.3/gcc/tree-cfg.c:3827 #3 0x00000000009e9c43 in verify_types_in_gimple_stmt (stmt=0x7ffff7fb5f00) at ../../gcc-4.6.3/gcc/tree-cfg.c:3984 #4 0x00000000009e9ea2 in verify_types_in_gimple_seq_2 (stmts=0x7ffff7fb4420) at ../../gcc-4.6.3/gcc/tree-cfg.c:4084 #5 0x00000000009ea096 in verify_types_in_gimple_seq (stmts=0x7ffff7fb4420) at ../../gcc-4.6.3/gcc/tree-cfg.c:4101 #6 0x0000000000820ec5 in gimplify_body (body_p=0x7ffff7fa9998, fndecl=0x7ffff7fa9900, do_parms=1 '\001') at ../../gcc-4.6.3/gcc/gimplify.c:7781 #7 0x000000000082155e in gimplify_function_tree (fndecl=0x7ffff7fa9900) at ../../gcc-4.6.3/gcc/gimplify.c:7870 #8 0x0000000000cb1eef in cgraph_analyze_function (node=0x7ffff7fc3000) at ../../gcc-4.6.3/gcc/cgraphunit.c:797 #9 0x0000000000cb2a90 in cgraph_analyze_functions () at ../../gcc-4.6.3/gcc/cgraphunit.c:983 (More stack frames follow...) (gdb) Note that void* seems to be of SImode, but the test case casts "void *x" to PTR64 which is a DImode pointer. Front end bug?