On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > > On 23 Sep 2007 09:54:29 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> 
> > > > wrote:
> > > > >
> > > > > Well, if the -fno-tree-salias flag now causes wrong-code bugs then I
> > > > > certainly agree that it should be eliminated.
> > > >
> > > > I didn't say that ;)  But I certainly expect salias to expose/hide bugs
> > > > there because MPT grouping will be changed.  At the moment
> > > > -fno-tree-salias simply ICEs.
> > > >
> > >
> > > As I understand it, -fno-tree-salias ICEs because a pass after salias
> > > needs alias information PROP_alias but no pass has executed
> > > TODO_rebuild_alias. We just need to build the alias information
> > > regardless of salias by adding a TODO_rebuild_alias to an earlier pass
> > > that is unconditionally executed (apply_inline?) or to a dummy pass
> > > dummy_todo_alias.
> > >
> > > Am I wrong? I have the same problem when I try to enable SSA at O0 and
> > > my current solution is the dummy pass.
> >
> > Right, a dummy pass after salias works.
> >
>
> And *before* salias? Does it make a difference? It suits me better for
> my purposes.

Can't do it before salias.

I didn't want to add a dummy pass mainly because i didn't want people
to get back to calling something like pass_may_alias.

If we add a dummy pass, can we verify it is only executed once per function?

Reply via email to