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