This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501



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

> Honestly, the availability check in valid_in_sets worries me, because
> it shouldn't be necessary.
> Names should be prevented from being ANTIC past the point of their
> definition through subtraction of TMP_GEN.

Yes, removing the AVAIL_OUT check in clean works.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]