This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Java] PATCH for optimization/12547
- From: law at redhat dot com
- To: Andreas Jaeger <aj at suse dot de>
- Cc: Jason Merrill <jason at redhat dot com>, Jan Hubicka <jh at suse dot cz>, Andrew Haley <aph at redhat dot com>, Jeff Sturm <jsturm at one-point dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 13 Nov 2003 08:40:23 -0700
- Subject: Re: [Java] PATCH for optimization/12547
- Reply-to: law at redhat dot com
In message <u83ccs8w45.fsf@gromit.moeb>, Andreas Jaeger writes:
>--=-=-=
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>law@redhat.com writes:
>
>> Rather than starting over again, could you give me the
>> dump_tree (stmt) output and tell me what bb->succ->flags looks like?
>
>(gdb) p bb->succ->flags
>$2 =3D 4097
>(gdb) p stmt
>No symbol "stmt" in current context.
>
>But stepping through the function I see that stmt is not assigned in
>this case at all.
OK. I can see how this could happen if we have a block with no statements
that somehow survives until this pass is run.
It's not even clear if goto elimination is useful at this statge now that
we've got lowered control statements and much better cfg cleanups. But
I'll go ahead and tweak things appropriately to avoid this problem while
we evaluate the usefulness of this hunk of goto elimination code.
Thanks,
jeff