Comment 17 for bug 827990

Confirmed on x86_64-linux with -Os on 4.6 and trunk.

(gdb) call debug_tree (exp)
 <addr_expr 0x2aaaaceb3fc0
    type <pointer_type 0x2aaaaab5d150
        type <integer_type 0x2aaaaab47540 unsigned int sizes-gimplified public unsigned SI
            size <integer_cst 0x2aaaaab35988 constant 32>
            unit size <integer_cst 0x2aaaaab35690 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0x2aaaaab47540 precision 32 min <integer_cst 0x2aaaaab359b0 0> max <integer_cst 0x2aaaaab35960 4294967295>
            pointer_to_this <pointer_type 0x2aaaaab5d150>>
        sizes-gimplified public unsigned DI
        size <integer_cst 0x2aaaaab35a50 constant 64>
        unit size <integer_cst 0x2aaaaab35a78 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0x2aaaaab5d150
        pointer_to_this <pointer_type 0x2aaaace99738>>
    constant
    arg 0 <component_ref 0x2aaaaceb7040 type <integer_type 0x2aaaaab47540 unsigned int>

        arg 0 <indirect_ref 0x2aaaaceb3f90 type <record_type 0x2aaaace993f0 a>

            arg 0 <integer_cst 0x2aaaace94938 constant 1241530624>
            t.i:12:9>
        arg 1 <field_decl 0x2aaaaab42720 a type <integer_type 0x2aaaaab47540 unsigned int>
            unsigned SI file t.i line 2 col 18 size <integer_cst 0x2aaaaab35988 32> unit size <integer_cst 0x2aaaaab35690 4>
            align 32 offset_align 128
            offset <integer_cst 0x2aaaaab356b8 constant 0>
            bit offset <integer_cst 0x2aaaaab35dc0 constant 0> context <record_type 0x2aaaace993f0 a> chain <field_decl 0x2aaaaab427b8 b>>
        t.i:12:9>
    t.i:12:7>

There is an INDIRECT_REF in the expression, that shouldn't happen. It is
from a CTOR that looks like

(gdb) call debug_generic_expr (ctor)
{&1241530624B->a, &1241530624B->b, 0B}

and we have a CTOR and not individual initializations because of Erics
const-pool changes I believe. &p->a is folded to &1241530624B->a even
before gimplification (but &1241530624B->a is "unfolded" - it's an
obfuscated constant).

We ICE from

#0 fancy_abort (
    file=0x1252a70 "/space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c",
    line=2638, function=0x1253700 "decode_addr_const")
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/diagnostic.c:893
#1 0x0000000000ca9016 in decode_addr_const (exp=0x2aaaaceb3fc0,
    value=0x7fffffff9b30)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2638
#2 0x0000000000ca97f0 in const_hash_1 (exp=0x2aaaaceb3fc0)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2734
#3 0x0000000000ca95db in const_hash_1 (exp=0x2aaaacea54e0)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2724
#4 0x0000000000cace7a in tree_output_constant_def (exp=0x2aaaacea54e0)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:3302
#5 0x000000000083a5f4 in gimplify_init_constructor (expr_p=0x7fffffffb3a8,
    pre_p=0x7fffffffccf8, post_p=0x7fffffffa928, want_value=0 '\000',
    notify_temp_creation=0 '\000')
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/gimplify.c:3833

and fold &p->a via c_fully_fold_internal.

Either the ADDR_EXPR case handling of this function or the COMPONENT_REF
case should be adjusted to fold it down to a constant.

Maybe there is a middle-end function somewhere to legitimize const
constructor elements though that I missed (and that the gimplifcation
misses).