Specifically, this one:
gdb/1091: Constructor breakpoints ignored
gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set
breakpoints

I see this happening in other situations.  For example, Intel's compiler
seems to produce two versions of each subroutine -- perhaps each is
optimized for a different architecture.  This means that, say, 'break
test.f:65' will usually put the breakpoint in the wrong one (c.f.
Murphy's Law).

I have implemented a fix, which works, presently I'm not too proud of
it, so I'm going to check it through before proposing the patch
formally..

However, does anyone have any problem with the approach.  

In summary, I change the linetable_entry structure to have a pointer,
'next', which will be the next linetable_entry in the table which has
the same source code and line.  

find_line_pc then actually modifies the symtab_and_line parameter to get
the linetable_entry (rather than just pulling the PC from it).

In the breakpoints code, if a symtab_and_line has several entries in the
chain of entries, it sets a new breakpoint for each one.  

This does mean that break test.f:65 will announce each breakpoint
separately.  Also, the first bpoint set is known by the line/source, the
others can be distinguished by their address.

It cures the breakpoint in the constructor issue, which is probably the
quickest way for a GNU compiler based check of the fix.

d.