This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Call maybe_clean_or_redirect_eh_stmt in gimple_fold_call (PR tree-optimization/51481)


On Tue, Dec 13, 2011 at 1:15 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Dec 13, 2011 at 01:05:30PM +0100, Richard Guenther wrote:
>> Yeah, I'm testing a followup patch that fixes the call in replace_uses_by
>> (that alone fixes the testcase in the PR).
>
> That patch looks good, but then forwprop has the same
> static void
> tidy_after_forward_propagate_addr (gimple stmt)
> {
> ?/* We may have turned a trapping insn into a non-trapping insn. ?*/
> ?if (maybe_clean_or_replace_eh_stmt (stmt, stmt)
> ? ? ?&& gimple_purge_dead_eh_edges (gimple_bb (stmt)))
> ? ?cfg_changed = true;
> ...
>
> Other spots are maybe ok, so if you want, the
> maybe_cleanup_or_replace_eh_stmt call from gimple_fold_call can be nuked
> afterwards. ?But what about that lookup_*/tree_could_throw_p check?
> Should it stay?

I don't think so, if we want to prevent fold_stmt from running into such
situation we should do it centrally (similar to the in-place variant).  But
I wouldn't go down this route without further evidence (read: a testcase
that we cannot fix otherwise).

Richard.

> ? ? ? ?Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]