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
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).
Confirmed on x86_64-linux with -Os on 4.6 and trunk.
(gdb) call debug_tree (exp)
pointer_ to_this <pointer_type 0x2aaaaab5d150>>
sizes- gimplified public unsigned DI
pointer_ to_this <pointer_type 0x2aaaace99738>>
<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>
size <integer_cst 0x2aaaaab35a50 constant 64>
unit size <integer_cst 0x2aaaaab35a78 constant 8>
align 64 symtab 0 alias set -1 canonical type 0x2aaaaab5d150
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>
unsigned SI file t.i line 2 col 18 size <integer_cst 0x2aaaaab35988 32> unit size <integer_cst 0x2aaaaab35690 4>
arg 1 <field_decl 0x2aaaaab42720 a type <integer_type 0x2aaaaab47540 unsigned int>
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 ( rguenther/ src/svn/ gcc-4_6- branch/ gcc/varasm. c", addr_const" ) rguenther/ src/svn/ gcc-4_6- branch/ gcc/diagnostic. c:893 3fc0, 0x7fffffff9b30) rguenther/ src/svn/ gcc-4_6- branch/ gcc/varasm. c:2638 3fc0) rguenther/ src/svn/ gcc-4_6- branch/ gcc/varasm. c:2734 54e0) rguenther/ src/svn/ gcc-4_6- branch/ gcc/varasm. c:2724 constant_ def (exp=0x2aaaacea 54e0) rguenther/ src/svn/ gcc-4_6- branch/ gcc/varasm. c:3302 init_constructo r (expr_p= 0x7fffffffb3a8, p=0x7fffffffccf 8, post_p= 0x7fffffffa928, want_value=0 '\000', temp_creation= 0 '\000') rguenther/ src/svn/ gcc-4_6- branch/ gcc/gimplify. c:3833
file=0x1252a70 "/space/
line=2638, function=0x1253700 "decode_
at /space/
#1 0x0000000000ca9016 in decode_addr_const (exp=0x2aaaaceb
value=
at /space/
#2 0x0000000000ca97f0 in const_hash_1 (exp=0x2aaaaceb
at /space/
#3 0x0000000000ca95db in const_hash_1 (exp=0x2aaaacea
at /space/
#4 0x0000000000cace7a in tree_output_
at /space/
#5 0x000000000083a5f4 in gimplify_
pre_
notify_
at /space/
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).