O0 cleanup_cfg vs debuggability

[Olivier Hainque <hainque at act-europe dot fr>]

Hello,


rest_of_compilation in 3.4 and rest_of_handle_jump2 in 3.5 read:

  /* Always do one jump optimization pass to ensure that JUMP_LABEL fields
     are initialized and to compute whether control can drop off the end
     of the function.  */
  [...]
  cleanup_cfg (...)

This optimization may affect debuggability even at O0, which is a bit
annoying. For instance, on x86-linux a breakpoint on the "break" statement in
the code below:

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

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

      return 0;
    }

is expected to be hit once for i == 3, and is instead hit several times,
the first one for i == 1. After the jump opt pass mentioned above, there
is just no code attached to the "break" line anymore.

A possible approach to address this would be to restrict what the pass does
e.g. by way of a CLEANUP_CONSERVATIVE mode flag passed-to/computed-by
cleanup_cfg if "optimize" is 0.

The comment implies that things must be achieved/computed, though, and I'm
unclear what parts may/may-not be bypassed.

A bit of help would be greatly appreciated here :) either comments/insights on
possible cleanup_cfg/try_optimize_cfg adjustments, on ideas on better ways to
address this.

Thanks in advance for your help,

Kind Regards,

Olivier