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/RFC] Fix PR optimization/15100


> and it seems that distribute_notes creates a dangling REG_RETVAL note
> from this sequence.  The appended patch is to get rid of the dangling
> REG_LIBCALL/REG_RETVAL notes.  But I don't understand the combiner well
> and I could be totally wrong about it.  The patch is tested for 3.4.0
> on i686-pc-linux-gnu and sh4-unknown-linux-gnu with full bootstraping
> and there are no new failures in the regression test on both targets.
> Any comments and suggestions are appreciated.
> 
> Regards,
> 	kaz
> --
> 	* combine.c (distribute_notes): Don't create a dangling
> 	REG_LIBCALL/REG_RETVAL note.
> 
> diff -uprN ORIG/gcc-3.4.0/gcc/combine.c LOCAL/gcc-3.4.0/gcc/combine.c
> --- ORIG/gcc-3.4.0/gcc/combine.c	2004-02-21 22:24:43.000000000 +0900
> +++ LOCAL/gcc-3.4.0/gcc/combine.c	2004-04-26 13:17:11.000000000 +0900
> @@ -12588,6 +12588,9 @@ distribute_notes (rtx notes, rtx from_in
>  		 libcall sequence, don't add the notes.  */
>  	      else if (XEXP (note, 0) == from_insn)
>  		tem = place = 0;
> +	      /* Don't add the dangling REG_RETVAL note.  */
> +	      else if (! tem)
> +		place = 0;
>  	    }
> 

If there is a REG_LIBCALL note, it should contain an instruction with a
REG_RETVAL note, and vice versa.  AFAICT we should just abort when tem
is 0.  Of course that begs the question why the inconsistency appears
initially  and how to fix it.


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