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.
No, after salias you need to run rebuild_alias. And for efficiency you'd of course remove the TODO from salias itself. Richard.
