Re: May delete_trivially_dead_insns delete trapping insns?

[Jan Hubicka <jh at suse dot cz>]

> Hi,
> 
> On Fri, 22 Nov 2002, Jan Hubicka wrote:
> 
> > It uses delete_insn_and_edges to remove the insns.
> 
> Hmm, right, I overlooked that.
> 
> > > Why for Java, but not for other languages?  If there are no trapping insns
> >
> > Because Java requires all exceptions to happen.  So you can't remove
> > dead insns that possibly trap.
> 
> Ok, then a patch is needed to prohibit that.  Will do that when I'm in
> prague ;-)
> 
> > Can you take a look why delete_insn_and_edges didn't removed the
> > edge?
> 
> It is possible that I confused it with some other place deleting the insn
> (I had a local patch prohibiting deleting trapping insns, got an error,
> removed the patch, got a different error, and before patching any further
> I wanted to clarify the semantics on the list ;) ).  For instance
> reg-stack.c also uses bare delete_insn() (without checking trapping btw.)

It only removes reg-reg moves converted to no-op moves that really should not trap.

> but in the end calls fixup_abnormal_edges().  The latter becomes mightyly
> confused if it finds exception edges but no trapping insns.
> 
> I wonder if for sanity-checking we should include a abort() in
> delete_insn(), which triggers, if
>   (flag_non_call_exceptions && may_trap_p())
> I bet it will trigger quite often for Java programs.  OTOH I'm not sure
> enough about Java semantics to know if the above really is disallowed

It really is :( I was chatting about this some time ago with Java
developers.  There are few places in GCC that attempts to avoid deleting
of such insns, but most of gcc backend is simply wrong in this respect.
Even worse the trap may be elliminated by fold-const, combine and CSE by
simply killing the memory reference...

Honza
> 
> 
> Ciao,
> Michael.