This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH for cleanup-handling in expand_return
- To: mitchell at codesourcery dot com
- Subject: Re: PATCH for cleanup-handling in expand_return
- From: Jeffrey A Law <law at upchuck dot cygnus dot com>
- Date: Wed, 19 May 1999 03:01:25 -0600
- cc: egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <19990518112258H.mitchell@codesourcery.com>you write:
>
> This is not a C++-specific patch. (I bet it will fix an analagous
> Java test-case as well, although I have no proof of this fact.) I
> will commit this under the "obvious fix" rule, unless someone objects
> in the near future. Jeff, please take a peek.
>
> In expand_return, we have code that transforms something like:
>
> return (x ? f() : g())
>
> into:
>
> if (x) return f(); else return g();
>
> in the hope of spotting more occurrences of tail recursion. (Our
> tail-recursion handling is pretty hokey, but there's nothing
> objectively *wrong* here.) However, we do not call
> start_cleanup_deferral and end_cleanup_deferral around the expansion
> of the conditionalized return statements in direct violation of this
> comment above start_cleanup_deferral:
>
> /* Mark when the context we are emitting RTL for as a conditional
> context, so that any cleanup actions we register with
> expand_decl_init will be properly conditionalized when those
> cleanup actions are later performed. Must be called before any
> expression (tree) is expanded that is within a conditional context. *
> /
>
> Oops. This means that cleanups for one side of the conditional are
> done on both sides, which is not the right thing. Nasty,
> hard-to-find, code-gen problems result.
Seems reasonable to me. I wonder how many other places in the compiler
to the same kinds of transformations. How unpleasant.
Can you check this in on both the branch and in the mainline sources?
Thanks,
jeff