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: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs


Andrew Pinski <pinskia@physics.uc.edu> writes:

> > 
> > > Hi,
> > > thanks for testing.  I've bootstrapped/regtested this variant of patch
> > > and comitted it as obvious.
> > 
> > Since this is an insn, we should not be copying it as it is just a link to that
> > insn.
> > 
> > Attached is a patch which fixes the ICE though I have not bootstrapped and tested
> > it yet.
> 
> Lets try to attach the patch this time.

> Index: emit-rtl.c
> ===================================================================
> --- emit-rtl.c	(revision 120287)
> +++ emit-rtl.c	(working copy)
> @@ -5302,7 +5302,7 @@
>  	else
>  	  REG_NOTES (new)
>  	       = gen_rtx_INSN_LIST (REG_NOTE_KIND (link),
> -		 copy_insn_1 (XEXP (link, 0)),  REG_NOTES (new));
> +		 XEXP (link, 0),  REG_NOTES (new));
>        }
>  
>    /* Fix the libcall sequences.  */

It seems to me this code should just be 

  for (link = REG_NOTES (insn); link; link = XEXP (link, 1))
    if (REG_NOTE_KIND (link) != REG_LABEL)
      {
	if (GET_CODE (link) == EXPR_LIST)
	  REG_NOTES (new)
		= gen_rtx_EXPR_LIST (REG_NOTE_KIND (link),
		  copy_rtx (XEXP (link, 0)),  REG_NOTES (new));
	else
	  REG_NOTES (new)
	       = gen_rtx_INSN_LIST (REG_NOTE_KIND (link),
		 copy_rtx (XEXP (link, 0)),  REG_NOTES (new));
      }

What do we expect to find in a REG_NOTE that requires the machinery of
copy_insn_1?  And calling copy_insn_1 without going through copy_insn
looks very wrong.

Ian


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