Hi Jason,
> I ran the tramp3d benchmark over 500 iterations before and after the
change and couldn't see any measurable difference in runtime. The
binary with my
> change was 0.4% smaller.
I'm going to go ahead and check it in; if a performance hit shows up on
the automated testing we can revisit the choice.
Unfortunately, this checkin broke the thread sanitizer:
r217669 | jason | 2014-11-17 20:08:02 +0100 (Mo, 17. Nov 2014) | 2 Zeilen
* cp-gimplify.c (genericize_cp_loop): Use LOOP_EXPR.
(genericize_for_stmt): Handle null statement-list.
therefore I would kindly ask you to revert this again.
After that patch some C++ functions moved the call to the __tsan_func_entry
into the loop.
And we get crashes or major memory leaks from this, if the software is compiled
with -fsanitize=thread.
This happens in a software package on which I currently work. It is called
Softing OPC UA Toolbox.
I found this in the generated assembler code by bisection:
000000000092747d
<_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_>:
92747d: 55 push %rbp
92747e: 48 89 e5 mov %rsp,%rbp
927481: 53 push %rbx
927482: 48 83 ec 18 sub $0x18,%rsp
927486: 48 89 7d e8 mov %rdi,-0x18(%rbp)
92748a: 48 89 75 e0 mov %rsi,-0x20(%rbp)
92748e: 48 8b 45 08 mov 0x8(%rbp),%rax
927492: 48 89 c7 mov %rax,%rdi
927495: e8 26 33 fe ff callq 90a7c0 <__tsan_func_entry@plt>
92749a: 48 8b 45 e8 mov -0x18(%rbp),%rax
92749e: 48 3b 45 e0 cmp -0x20(%rbp),%rax
9274a2: 74 3d je 9274e1
<_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x64>
9274a4: 48 8b 5d e8 mov -0x18(%rbp),%rbx
9274a8: 48 89 d8 mov %rbx,%rax
9274ab: 48 85 db test %rbx,%rbx
9274ae: 74 0b je 9274bb
<_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x3e>
9274b0: 48 89 c2 mov %rax,%rdx
9274b3: 83 e2 07 and $0x7,%edx
9274b6: 48 85 d2 test %rdx,%rdx
9274b9: 74 0f je 9274ca
<_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x4d>
9274bb: 48 89 c6 mov %rax,%rsi
9274be: 48 8d 3d 1b a3 f8 00 lea 0xf8a31b(%rip),%rdi #
18b17e0 <DW.ref.__gxx_personality_v0+0x11878>
9274c5: e8 06 36 fe ff callq 90aad0
<__ubsan_handle_type_mismatch@plt>
9274ca: 48 89 df mov %rbx,%rdi
9274cd: e8 1b 09 00 00 callq 927ded
<_ZSt11__addressofIN18SoftingOPCToolbox55ValueEEPT_RS2_>
9274d2: 48 89 c7 mov %rax,%rdi
9274d5: e8 21 09 00 00 callq 927dfb
<_ZSt8_DestroyIN18SoftingOPCToolbox55ValueEEvPT_>
9274da: 48 83 45 e8 20 addq $0x20,-0x18(%rbp)
9274df: eb ad jmp 92748e
<_ZNSt12_Destroy_auxILb0EE9__destroyIPN18SoftingOPCToolbox55ValueEEEvT_S5_+0x11>
9274e1: e8 da 2c fe ff callq 90a1c0 <__tsan_func_exit@plt>
9274e6: 48 83 c4 18 add $0x18,%rsp
9274ea: 5b pop %rbx
9274eb: 5d pop %rbp
9274ec: c3 retq
9274ed: 90 nop
see the jmp at 9274df: it jumps to _before_ the tsan_func_entry.
I am not sure how to locate the source code of the above assembler section.
But I'd guess, it must be some kind of automatically generated default
destructor.
All I can say in the moment, that it is was working perfectly before Nov 17.
Thanks
Bernd.
