This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [rfa, vrp] fix eh rewrite acats cxb3011 failure
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 7 Sep 2009 22:54:41 +0200
- Subject: Re: [rfa, vrp] fix eh rewrite acats cxb3011 failure
- References: <4AA56C55.3080202@redhat.com>
On Mon, Sep 7, 2009 at 10:25 PM, Richard Henderson<rth@redhat.com> wrote:
> The only remaining regression from mainline for my EH rewrite
> is this odd failure of cxb3011, which looks for all the world
> like a latent bug in VRP.
SCCVN you mean.
>> (gdb) call debug_gimple_stmt ($)
>> # .MEM_1028 = VDEF <.MEM_1026>
>> tc_string.F[1 ...]{lb: 1 sz: 1} =
>> VIEW_CONVERT_EXPR<character[1:5]>(*SR.131_874);
>>
>
> This statement triggers a vec_assert_fail here:
>
>> ? ? ?i = VEC_length (vn_reference_op_s, vr->operands) - 1;
>> ? ? ?j = VEC_length (vn_reference_op_s, lhs) - 1;
>> ? ? ?while (j >= 0 && i >= 0
>> ? ? ? ? ? ? && vn_reference_op_eq (VEC_index (vn_reference_op_s,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? vr->operands, i),
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?VEC_index (vn_reference_op_s, lhs, j)))
>> ? ? ? ?{
>> ? ? ? ? ?i--;
>> ? ? ? ? ?j--;
>> ? ? ? ?}
>
> with I=2, J=3 on entry to the loop. ?This means we run out of VR->OPERANDS
> values before we run out of LHS values.
>
> It looks like we'll DTRT if we just add another check for I>=0 there in the
> while loop. ?That said, I don't know whether it's indicative of a bug
> elsewhere that this case occurs.
>
> And while I'm at it, there's a memory leak just below where we fail to free
> the LHS vector.
>
> Ok?
Yes.
Thanks,
Richard.
>
> r~
>