Re: failing to copy NOTEs

[Bernd Schmidt <bernds at balti dot cygnus dot co dot uk>]

On 30 Jan 2000, Alexandre Oliva wrote:
 
> >> For some reason, that I'm still investigating and that was introduced
> >> after gcc_ss_20000117, copy_rtx_and_substitute() is now being asked to
> >> copy a sequence of insns containing a NOTE_DELETED
> 
> Could someone please comment on or approve this patch?  This bug has
> been bugging me for two weeks now, and the fix is so simple that I'm
> almost checking it in under the obviously correct rule.  But I'd
> prefer to have some feedback first, preferably before the next
> snapshot.
> 
> The related messages are:
> http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00978.html
> http://gcc.gnu.org/ml/gcc-patches/2000-01/msg01068.html

I've had a brief look.  While the patch probably isn't wrong, I think there
is another problem lurking in this code.  The abort you get from the testcase
happens when copy_rtx_and_substitute is called from integrate_decl_tree
(the note is the DECL_RTL of some decl).  Later on, the note is "copied"
again (using emit_note), when processing the insn chain.  This means you'll
get two copies of it, the one in the copied DECL_RTL being different from
the one in the insn chain, which is most likely not what's intented.

I'm not sure how best to fix this.  One approach might be to split
integrate_decl_tree into two functions, one of which is called after the
insn chain is copied.  This one would do the copying of DECL_RTLs.  Not
sure whether that would have any unpleasant side-effects, though.
Another approach would be to implement tree-based inlining for all
frontends :)

Bernd