------- Comment #25 from dberlin at gcc dot gnu dot org 2009-07-15 14:29
-------
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, Jul 15, 2009 at 9:58 AM, rguenther at suse dot
de<gcc-bugzi...@gcc.gnu.org> wrote:
>
>
> ------- Comment #24 from rguenther at suse dot de 2009-07-15 13:58 -------
> Subject: Re: [4.4/4.5 Regression] internal
> compiler error: in compute_antic, at tree-ssa-pre.c:2501
>
> On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
>
>> ------- Comment #23 from dberlin at gcc dot gnu dot org 2009-07-15 13:46
>> -------
>> Subject: Re: [4.4/4.5 Regression] internal
>> compiler error: in compute_antic, at tree-ssa-pre.c:2501
>>
>> a_1 shouldn't be in the maximal set. If it is, that's a bug.
>
> D.1251_5 = a_1->flag;
>
> so it's even in exp_gen.
I expect it got in exp_gen through add_to_exp_gen.
But the check there should have ensured it didn't get into the maximal set.
> And because a_1 is in the maximal set
> b_2 has to.
>
> Well, as you asy - we'll see if it bootstraps ;)
>
>> The history here:
>>
>> We didn't use to have a check for domination in avail_out.
>> As a result, values only died if they were in TMP_GEN.
>> (This is what is *supposed* to happen. At some point we added a check
>> for availability to valid_in_sets and i can't remember why).
>> PHI values are not in TMP_GEN, so they will never disappear from the
>> set once in it.
>>
>> Nowadays, it may be safe to put phi values in there.
>
> Where? in TMP_GEN? That doesn't work.
Then how do we expect it to ever fall out of the set?
IE If a phi value enters ANTIC, what is going to prevent it from being
considered ANTIC all the way up the CFG?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
