Re: [patch] Relax assertion in vn_reference_lookup_3

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Oct 30, 2009 at 11:14 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Fri, Oct 30, 2009 at 7:43 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Hi,
>>
>> the attached testcase triggers the assertion in vn_reference_lookup_3
>>
>> ? ? /* Adjust *ref from the new operands. ?*/
>> ? ? if (!ao_ref_init_from_vn_reference (&r, vr->set, vr->type, vr->operands))
>> ? ? ? return (void *)-1;
>> ? ? gcc_assert (ref->size == r.size);
>>
>> when compiled at -O on x86:
>>
>> (gdb) p ref->size
>> $4 = 64
>> (gdb) p r.size
>> $5 = 48
>> (gdb) p debug_gimple_stmt(def_stmt)
>> # .MEM_6 = VDEF <.MEM_2(D)>
>> _init = _init_1(D)->field1;
>>
>> $6 = void
>> (gdb) p debug_tree(gimple_assign_rhs1 (def_stmt))
>> ?<component_ref 0xf7cf84b0
>> ? ?type <record_type 0xf7d8af3c p__rec48 sizes-gimplified visited packed DI
>> ? ? ? ?size <integer_cst 0xf7cda594 constant visited 64>
>> ? ? ? ?unit size <integer_cst 0xf7cda5b0 constant visited 8>
>> ? ? ? ?align 32 symtab 0 alias set -1 canonical type 0xf7d8af3c
>> ? ? ? ?fields <field_decl 0xf7d1e3f4 w1andw2 type <record_type 0xf7d8adac
>> p__rec32>
>> ? ? ? ? ? ?SI file p.ads line 22 col 7
>> ? ? ? ? ? ?size <integer_cst 0xf7cda498 constant visited 32>
>> ? ? ? ? ? ?unit size <integer_cst 0xf7cda284 constant 4>
>> ? ? ? ? ? ?align 32 offset_align 128
>> ? ? ? ? ? ?offset <integer_cst 0xf7cda834 constant visited 0>
>> ? ? ? ? ? ?bit offset <integer_cst 0xf7cda850 constant 0> context
>> <record_type 0xf7d8af3c p__rec48> chain <field_decl 0xf7d1e450 w3>>
>> ? ? ? ?Ada size <integer_cst 0xf7d95690 constant visited 48>
>> ? ? ? ?pointer_to_this <pointer_type 0xf7d98514>>
>>
>> ? ?arg 0 <indirect_ref 0xf7d968a0
>> ? ? ? ?type <record_type 0xf7d98190 p__rec_type sizes-gimplified visited
>> packed BLK size <integer_cst 0xf7d95690 48>
>> ? ? ? ? ? ?unit size <integer_cst 0xf7cdaad4 constant visited 6>
>> ? ? ? ? ? ?align 8 symtab 0 alias set -1 canonical type 0xf7d98190 fields
>> <field_decl 0xf7d1e678 field1> Ada size <integer_cst 0xf7d95690 48>
>> reference_to_this <reference_type 0xf7d982bc>>
>>
>> ? ? ? ?arg 0 <ssa_name 0xf7ce87b8 type <reference_type 0xf7d982bc>
>> ? ? ? ? ? ?visited var <parm_decl 0xf7cfe4b0 _init>def_stmt GIMPLE_NOP
>>
>> ? ? ? ? ? ?version 1
>> ? ? ? ? ? ?ptr-info 0xf7d6d488>>
>> ? ?arg 1 <field_decl 0xf7d1e678 field1 type <record_type 0xf7d8af3c p__rec48>
>> ? ? ? ?external packed bit-field nonaddressable DI file p.ads line 34 col 7
>> size <integer_cst 0xf7d95690 48> unit size <integer_cst 0xf7cdaad4 6>
>> ? ? ? ?align 1 offset_align 128 offset <integer_cst 0xf7cda834 0> bit offset
>> <integer_cst 0xf7cda850 0> bit_field_type <record_type 0xf7d8af3c p__rec48>
>> context <record_type 0xf7d98190 p__rec_type>>
>> ? ?p.ads:34:7>
>>
>> field1 is a 48-bit aggregate bitfield so _init_1(D)->field1 is a 48-bit
>> extraction, despite its 64-bit access type. ?This is a common pattern in Ada.

Of course I question this inconsistency - how do we expand a copy statement
that copies 48 bits to 64 bits ... (IMHO this shouldn't be valid gimple)

But well, this is a well-known odd situation we face with TYPE_SIZE vs.
DECL_SIZE for FIELD_DECLs...

>> So I'm proposing to relax the assertion and bail out if the sizes don't match.
>>
>> Tested on i586-suse-linux, OK for mainline?

Ok.

Thanks,
Richard.