https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770
--- Comment #4 from petschy at gmail dot com --- Clarification: I double checked now, and the templated and the non-templated versions (do_print vs do_print2) are the same, with the same disassembly, only the addresses differing. This is true for 4.9.1 and for 5.0, too. So my previous statement that these two versions of the functions behave differently doesn't hold. So I sum up again: 4.9.1: - the printf (line 62 & 122) is stepped on in each loop iteration, this is the jmp insn in the disassembly, that jumps to the beginning of the loop. the insns for the printf start on the next insn. - if the condition is true in line 25/85, the break; in line 26 is skipped and it stops on line 36/96, which is the next statement after the break; - upon loop exit, after stepping over the final printf (line 62/122), it jumps back to the while() in line 11/71, and only prints if this while() is stepped over, then goes to the closing brace in line 63/123 5.0: - the printf (62/122) is not stepped on in each iteration, OK - break; is not stepped on in line 25/85, as above, however, if the condition is true, it jumps to line 31/91, the closing brace of the loop, and then to line 36/96, the next statement. I think it should go immediately to the next statement. The exception would be to run dtors upon loop exit, but this is not the case now, as the variables are plain chars. - the loop exit is OK, it doesn't jump back to the while() after the printf, and prints when the printf is stepped over. If I put a breakpoint to line 26/86 in the debugger (the break; that is skipped), gdb says that placed the breakpoints on the same lines. However, when single-stepping, it will break on line 28/88, if the condition is false. This is the statement after the if() w/ the break; If the condition is true, it won't stop on the breakpoint. This is true for both gcc versions tested.
