This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Fix PR rtl-optimization/19462 reorg: return andcurrent_function_epilogue_delay_list
- From: Jeffrey A Law <law at redhat dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 18 Jan 2005 09:20:20 -0700
- Subject: Re: [RFA:] Fix PR rtl-optimization/19462 reorg: return andcurrent_function_epilogue_delay_list
- Organization: Red Hat, Inc
- References: <Pine.BSF.4.58.0501180911530.16811@dair.pair.com>
- Reply-to: law at redhat dot com
On Tue, 2005-01-18 at 09:13 -0500, Hans-Peter Nilsson wrote:
> See the PR and also PR target/7042. Xfailed test-case committed
> in gcc/testsuite/gcc.dg/torture/pr19462-1.c.
>
> The problem is hopefully completely spelled out in the comment
> (assuming a reader familiar with this machinery): once
> current_function_epilogue_delay_list is non-null, any new
> non-exceptional return paths must also run the insns in
> current_function_epilogue_delay_list and the code wasn't caring
> for that being non-null. However, moving those insns seems
> excessive for obsoleted functionality, so I'd prefer not
> creating the new return paths. Making sure that return insns
> don't clash with current_function_epilogue_delay_list could be
> made the responsibility of the target, but why doing it for each
> target when it can be handled by the middle-end for known
> invalid cases?
>
> I also seek comments (perhaps approval) regarding removing all
> traces of current_function_epilogue_delay_list and related
> macros on 4.1, because it's only used for textual epilogues, and
> we don't want them, right? Particularly when this functionality
> has shown a tendency to attract bugs related to filling
> delay-slots of normal insns.
>
> No regressions tested cross to cris-axis-linux-gnu, bootstrapped
> and checked native on sparc-sun-solaris2.8 (c,c++,java,objc)
> (which has delay-slots but doesn't have textual epilogues; it
> does use that framework, but only to output a nop in some rare
> cases).
>
> Ok to commit?
>
> PR rtl-optimization/19462
> * reorg.c (find_end_label): Create return insn only if
> current_function_epilogue_delay_list is empty.
OK. I'm not entirely sure it fixes all the issues in this space, but
it ought to be safe.
As for killing current_function_epilogue_delay_list and its related
braindamanged -- go for it. Only two ports use it (cris and arc), so
it shouldn't be a huge task.
Jeff