Re: [PATCH] prevents labels referenced in the exception table to be deleted

[Christian BRUEL <christian dot bruel at st dot com>]

Steven Bosscher wrote:
> On Thu, Feb 11, 2010 at 11:25 AM, Christian BRUEL
> <christian.bruel@st.com> wrote:
> > > > A label referenced in the exception table is not dead and should not be
> > > > deleted when jumps are merged, This patch just prevents this.
> > > Looks like this would slow down the compiler for all targets, just to
> > > make things work on the very few targets that still use the archaic
> > > dbr-sched pass in reorg...  Please, no.
> > OK, I agree. And this implementation was rather other shot and naive.
> > On the other hand this impacts the sparc, frv, fr30, cris, iq2000, picochip,
> > arc, pa, mips and h83200, that have define_delay and use the dbr sched.
> >
> > What about just marking the label as PRESERVED_P as attached ? that solves
> > the problem more generally and guards against any dangerous call to
> > delete_insn.
>
> Are you sure you are attacking this problem from the right angle? It
> seems to me that a problem like this would have been noticed long ago
> if the problem is that the label is not marked PRESERVED_P. More
> likely, the problem is in reorg.c itself,

yes I think I'm sure.

delete_related_insn is used from reorg itself or cleanup_cfg with 
CLEANUP_EXPENSIVE mode, which is never done after pass_rtl_eh that 
creates the landing pad labels. So first point, the bug can only occur 
one targets that use dbr_sched (not x86).

Then this new landing_pad creation code is only in the trunk. So we 
didn't have the opportunity to stress it in a larger scale from a stable 
branch. How lucky I was, I stepped in it first of course :(

Looking at the 4.4 branch, the label WAS maked PRESERVED. There was a 
call to find_exception_handler_label() after the landing pad creation 
that set LABEL_PRESERVE_P with a call to add_ehl_entry().

In the trunk, this function has been removed, so the PRESERVED marker 
lost. looking at the history it seems to come from Revision 145747

 and you should try to figure
> out why it tries to delete the label in the first place.
because its unreachable from the control flow, after redirect_jump.

I'm now convinced that remarking the label as PRESERVED_P is necessary. 
 I will of course validate this change if it is accepted on both the 
reference x86 target and another one that use dbr_reorg .

Thanks

Christian

> Ciao!
> Steven