This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] failures found while pounding on GCC trunk
On 9/23/07, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> On 23/09/2007, Richard Guenther <richard.guenther@gmail.com> wrote:
> > On 9/23/07, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> > > On 23/09/2007, Richard Guenther <richard.guenther@gmail.com> wrote:
> > > > On 23 Sep 2007 09:54:29 -0700, Ian Lance Taylor <iant@google.com> 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.