Hi,

this fixes an issue with the gdb step-over aka. "n" command.

Apologies, the motivation for this patch was from sub-optimal
debug experience using some gcc code involving inlined functions,
and initially I tried to convince gcc folks that it is in fact a
gcc bug, but...

It can be seen when you debug an optimized stage-3 cc1
it does not affect -O0 code, though.

Note: you can use "gcc -S hello.c -wrapper gdb,--args" to invoke cc1 with
debugger attached.

This example debug session will explain the effect.

(gdb) b get_alias_set
Breakpoint 5 at 0xa099f0: file ../../gcc-trunk/gcc/alias.c, line 837.
(gdb) r
Breakpoint 5, get_alias_set (t=t@entry=0x7ffff7ff7ab0) at ../../gcc-trunk/gcc/alias.c:837
837	  if (t == error_mark_node
(gdb) n
839		  && (TREE_TYPE (t) == 0 || TREE_TYPE (t) == error_mark_node)))
(gdb) n
3382	  return __t;  <-- now we have a problem: wrong line info here
(gdb) bt
#0  get_alias_set (t=t@entry=0x7ffff7ff7ab0) at ../../gcc-trunk/gcc/tree.h:3382
#1  0x0000000000b25dfe in set_mem_attributes_minus_bitpos (ref=0x7ffff746f990, t=0x7ffff7ff7ab0, objectp=1, bitpos=...)
    at ../../gcc-trunk/gcc/emit-rtl.c:1957
#2  0x0000000001137a55 in make_decl_rtl (decl=0x7ffff7ff7ab0) at ../../gcc-trunk/gcc/varasm.c:1518
#3  0x000000000113b6e8 in assemble_variable (decl=0x7ffff7ff7ab0, top_level=<optimized out>, at_end=<optimized out>, 
    dont_output_data=0) at ../../gcc-trunk/gcc/varasm.c:2246
#4  0x000000000113f0ea in varpool_node::assemble_decl (this=0x7ffff745b000) at ../../gcc-trunk/gcc/varpool.c:584
#5  0x000000000113fa17 in varpool_node::assemble_decl (this=0x7ffff745b000) at ../../gcc-trunk/gcc/varpool.c:750

The reason for this is a line number information that is exactly at
the end of the inlined function, but there is no code at that place,
only variable values (views) are declared there.  Unfortunately
the next instruction is again in the main program, but due to -gstatement-frontiers
those do not have the is_stmt and are completely ignored by gdb at the moment.


This patch fixes the effect by rewriting the is_stmt attribute of the next
location info under certain conditions.

I have no idea how to write a test case for this since it happens only in optimized code,
and only under very special conditions.


Thanks
Bernd.