It looks like GDB has a little difficulty with debug info including column information in the line table (which Clang on Linux emits by default).

Take, for example:

 make check RUNTESTFLAGS="CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++ CFLAGS_FOR_TARGET='-w -fstandalone-debug ' gdb.base/consecutive.exp"

(after recent changes - so you'll need a recent (>= r223872) source-built Clang)

GDB fails the test here, because, when breaking on the 'next' instruction in the same line, instead of getting this (which can be reproduced by passing clang -gno-column-info):

  Breakpoint 3, 0x00000000004005ab in foo () at testsuite/gdb.base/consecutive.c:10

GDB produces:

  Breakpoint 3, foo () at testsuite/gdb.base/consecutive.c:10

The difference in the line table is:

--- old.txt     2014-12-11 15:36:09.161528155 -0800
+++ new.txt     2014-12-11 15:35:44.925266367 -0800
@@ -3,7 +3,7 @@
 
 .debug_line contents:
 Line table prologue:
-    total_length: 0x00000067
+    total_length: 0x00000080
          version: 2
  prologue_length: 0x00000048
  min_inst_length: 1
@@ -31,8 +31,14 @@
 Address            Line   Column File   ISA Discriminator Flags
 ------------------ ------ ------ ------ --- ------------- -------------
 0x00000000004005a0      9      0      1   0             0  is_stmt
-0x00000000004005a4     10      0      1   0             0  is_stmt prologue_end
+0x00000000004005a4     10     10      1   0             0  is_stmt prologue_end
+0x00000000004005ab     10     17      1   0             0  is_stmt
+0x00000000004005b2     10     24      1   0             0  is_stmt
+0x00000000004005b9     10     31      1   0             0  is_stmt
+0x00000000004005c0     10     38      1   0             0  is_stmt
+0x00000000004005c7     10     45      1   0             0  is_stmt
+0x00000000004005ce     10     52      1   0             0  is_stmt
 0x00000000004005e0     14      0      1   0             0  is_stmt
-0x00000000004005e4     15      0      1   0             0  is_stmt prologue_end
-0x00000000004005ef     16      0      1   0             0  is_stmt
-0x00000000004005fa     16      0      1   0             0  is_stmt end_sequence
+0x00000000004005e4     15      3      1   0             0  is_stmt prologue_end
+0x00000000004005ef     16      1      1   0             0  is_stmt
+0x00000000004005fa     16      1      1   0             0  is_stmt end_sequence

So my guess is that GDB treated the 0x4005ab line as a separate stop point (and didn't include the offset) because it's a separate line in the line table, even though it has the same line number and a different column number (but GDB didn't include the column number in the break information, just the line number).

I guess GDB should include the offset if it's in a contiguous run of the same line, perhaps? But I'm not sure. For now I'll XFAIL (at least in Clang's copy of GDB 7.5 for testing purposes - might get a chance to upstream the XFAIL at some point) this test under Clang+GDB with this bug number.

[some of the reverse debugging test cases fail with my recent improvements to Clang's column information too, but I haven't investigated them yet - the reverse debugging tests seem particularly fragile, as a general observation]