Created attachment 28156 [details]
nonreduced test case

I am continuing to make compilers fail in new and interesting ways :)


Problem:
If I set (in gdb) a breakpoint on a one of my C-style variadic functions, it will not get hit. Other variadic functions are fine.

In addition, using gdb's 'step' command will cause the rest of the program to run, instead of actually stepping (now that I think about it this is probably an additional bug, in gdb)

This occurs only at optimization level zero. I have reproduced with g++ 4.6 and 4.7 from Debian and from Gentoo.

This likely only happens on amd64 because it is dependent on the way va_list is implemented.


Analysis:
The problem is because the breakpoint gets set on the line after a jump that happens to be taken. Someone who knows a lot more about debuginfo than I could probably automate this and take gdb out of the picture.

=====

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/main...done.
(gdb) break cxxstdio::do_scanf
Breakpoint 1 at 0x401564: file src/common/cxxstdio.hpp, line 115.
(gdb) disassemble cxxstdio::do_scanf
Dump of assembler code for function cxxstdio::do_scanf(const_string, char const*, ...):
   0x0000000000401540 <+0>:     push   rbp
   0x0000000000401541 <+1>:     mov    rbp,rsp
   0x0000000000401544 <+4>:     sub    rsp,0xf0
   0x000000000040154b <+11>:    mov    QWORD PTR [rbp-0x98],rcx
   0x0000000000401552 <+18>:    mov    QWORD PTR [rbp-0x90],r8
   0x0000000000401559 <+25>:    mov    QWORD PTR [rbp-0x88],r9
   0x0000000000401560 <+32>:    test   al,al
   0x0000000000401562 <+34>:    je     0x401584 <cxxstdio::do_scanf(const_string, char const*, ...)+68>
   0x0000000000401564 <+36>:    movaps XMMWORD PTR [rbp-0x80],xmm0  // <-- breakpoint is here, not reached if the 'je' is taken, i.e. if al is 0
   0x0000000000401568 <+40>:    movaps XMMWORD PTR [rbp-0x70],xmm1
   0x000000000040156c <+44>:    movaps XMMWORD PTR [rbp-0x60],xmm2
   0x0000000000401570 <+48>:    movaps XMMWORD PTR [rbp-0x50],xmm3
   0x0000000000401574 <+52>:    movaps XMMWORD PTR [rbp-0x40],xmm4
   0x0000000000401578 <+56>:    movaps XMMWORD PTR [rbp-0x30],xmm5
   0x000000000040157c <+60>:    movaps XMMWORD PTR [rbp-0x20],xmm6
   0x0000000000401580 <+64>:    movaps XMMWORD PTR [rbp-0x10],xmm7
   0x0000000000401584 <+68>:    mov    QWORD PTR [rbp-0xe8],rdx
   0x000000000040158b <+75>:    mov    QWORD PTR [rbp-0xe0],rdi
   0x0000000000401592 <+82>:    mov    QWORD PTR [rbp-0xd8],rsi
   0x0000000000401599 <+89>:    mov    DWORD PTR [rbp-0xc8],0x18
   0x00000000004015a3 <+99>:    mov    DWORD PTR [rbp-0xc4],0x30
   0x00000000004015ad <+109>:   lea    rax,[rbp+0x10]
   0x00000000004015b1 <+113>:   mov    QWORD PTR [rbp-0xc0],rax
   0x00000000004015b8 <+120>:   lea    rax,[rbp-0xb0]
   0x00000000004015bf <+127>:   mov    QWORD PTR [rbp-0xb8],rax
   0x00000000004015c6 <+134>:   lea    rax,[rbp-0xe0]
   0x00000000004015cd <+141>:   mov    rdi,rax
   0x00000000004015d0 <+144>:   call   0x401628 <const_array<char>::data()>
   0x00000000004015d5 <+149>:   lea    rdx,[rbp-0xc8]
   0x00000000004015dc <+156>:   mov    rcx,QWORD PTR [rbp-0xe8]
   0x00000000004015e3 <+163>:   mov    rsi,rcx
   0x00000000004015e6 <+166>:   mov    rdi,rax
   0x00000000004015e9 <+169>:   call   0x400c90 <vsscanf@plt>
   0x00000000004015ee <+174>:   leave  
   0x00000000004015ef <+175>:   ret    
End of assembler dump.
(gdb)

=====

The attached testcase is 500kB. I tried to reduce it, but changing what gets fed to the preprocessor makes the bug sometimes go away (however any single source is stable).