[Bug middle-end/50266] [4.6/4.7 Regression] internal compiler error: in decode_addr_const, at varasm.c:2638

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm-linux-gnueabi
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-09-02
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org, jsm28 at gcc dot
                   |                            |gnu.org
      Known to work|                            |4.5.3
   Target Milestone|---                         |4.6.2
            Summary|internal compiler error: in |[4.6/4.7 Regression]
                   |decode_addr_const, at       |internal compiler error: in
                   |varasm.c:2638               |decode_addr_const, at
                   |                            |varasm.c:2638
     Ever Confirmed|0                           |1
      Known to fail|                            |4.6.1, 4.7.0

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-02 08:22:43 UTC ---
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).