cpython/build35.lto$ ./python ../3.5/Lib/test/test_gdb.py
GDB version 7.10:
    GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10
...
======================================================================
FAIL: test_tuples (__main__.PrettyPrintTests)
Verify the pretty-printing of tuples
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../3.5/Lib/test/test_gdb.py", line 359, in test_tuples
    self.assertGdbRepr(tuple(), '()')
  File "../3.5/Lib/test/test_gdb.py", line 279, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "../3.5/Lib/test/test_gdb.py", line 255, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 at 0x4cc310\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".\n\nBreakpoint 1, builtin_id ()\n#0  builtin_id ()\n'
Breakpoint 1 at 0x4cc310
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, builtin_id ()
#0  builtin_id ()

I don't know the right thing to do here.  This might depend on compiler, linker, arch and gdb version?  Are it's LTO executables debuggable?  It's not clear to me that we can do anything about this.  We may just want to skip the test when configured --with-lto.  Or perhaps this is an indication that this specific toolchain's LTO build (x86_64, ubuntu wily gcc 5.2.1 and gdb 7.1.0) has issues and shouldn't be used?