This is the mail archive of the gcc@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: O0 cleanup_cfg vs debuggability


rth@redhat.com (Richard Henderson)  wrote on 12.08.04 in <20040813005227.GB3873@redhat.com>:

> On Thu, Aug 12, 2004 at 03:44:35PM -0700, James E Wilson wrote:
> > Or perhaps we should take a completely different approach here.  Instead
> > of trying to maintain the block info in the rtl, just accept that blocks
> > may get lost, and if we have unreferenced blocks left over in
> > reemit_insn_block_notes before the reorder_blocks call, then we just
> > insert them in some arbitrary place.  It doesn't really matter where,
> > since they have a 0 sized address span anyways.
>
> It's this zero span argument that elides the block in the
> first place.  Since its a zero sized span, you can never
> be inside it, so *any* listing of currently active local
> variables will not include these.
>
> I have no idea what good is being attempted by keeping them.

Why are we suddenly talking about live variables, when the original  
question was about control flow?

That is, setting break points in places that optimization has caused to  
vanish, and thus getting triggered in the wrong situation.

The original example was this:


    int main (void)
    {
      int a = 0, i;

      for (i = 1; i <= 10; i ++)
	{
	  if (i < 3)
	    a = 1;
	  else
	    break;             <<< breakpoint here
	  a = 2;
	}

      return 0;
    }


MfG Kai


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