Re: [Patch] pr65779 - [5/6 Regression] undefined local symbol on powerpc

[Alan Modra <amodra@gmail.com>]

On Mon, Apr 20, 2015 at 09:35:07AM +0200, Jakub Jelinek wrote:
> On Mon, Apr 20, 2015 at 12:40:49PM +0930, Alan Modra wrote:
> > with the log for the ubsan fails
> > /src/gcc-5/gcc/testsuite/c-c++-common/ubsan/object-size-10.c:19:11: runtime error: index 128 out of bounds for type 'char [128]'
> > /src/gcc-5/gcc/testsuite/c-c++-common/ubsan/object-size-10.c:19:11: runtime error: load of address 0x0804a000 with insufficient space for an object of type 'char'
> > 0x0804a000: note: pointer points here
> > <memory cannot be printed>
> 
> The issue here is that libsanitizer wants to print some context around the
> variable, and doesn't try too hard, so if the variable is too close to the
> end of the RW PT_LOAD, you get different message from what is expected.

Thanks for the info.  I don't tend to run sanitizer tests, so this was
the first time I'd seen such a failure.

> Just wonder if using an
>   auto_vec<basic_block, 5> live_bbs;

OK, done.

> > +	  FOR_BB_INSNS_REVERSE (tmp_bb, dinsn)
> > +	    {
> > +	      if (dinsn == insn)
> > +		break;
> > +	      if (DEBUG_INSN_P (dinsn)
> > +		  && insn_uses_reg (dinsn, dregno, end_dregno))
> > +		{
> > +		  if (*split_p)
> > +		    /* If split, then we will be moving insn into a
> > +		       newly created block immediately after the entry
> > +		       block.  Move the debug info there too.  */
> > +		    emit_debug_insn_after (PATTERN (dinsn), bb_note (bb));
> > +		  delete_insn (dinsn);
> 
> Debug insns should never be deleted, nor moved.  You should either
> reset them
> (INSN_VAR_LOCATION_LOC (insn) = gen_rtx_UNKNOWN_VAR_LOC (); plus
> df_insn_rescan_debug_internal (insn);), or

I had it that way in my first patch, then decided to try deleting..

I can certainly change it back even if only to do it the standard way
for safety's sake, but I'm curious as to why they can't be deleted in
this special case.  My thinking was that we're on a chain of blocks
starting at the entry where there is a single outgoing live edge for
the register being used.  So there shouldn't be any need for a debug
insn to mark info about the variable as invalid.

-- 
Alan Modra
Australia Development Lab, IBM