gcc version 3.5.0 20040704 (experimental) void f(void) { unsigned long x[16]; memset(x, 0, sizeof(x)); } generates f: .LFB2: subq $136, %rsp .LCFI0: movl $128, %edx xorl %esi, %esi movq %rsp, %rdi call memset addq $136, %rsp ret but when the 0 is changed to 0xff or any other value != 0 you get f: .LFB2: subq $16, %rsp .LCFI0: addq $16, %rsp ret (which btw is also weird because it leaks 16 bytes, but that's a differen issue) I would expect the 0 memset to be optimized away too. Looking at the code builtin_memset calls clear_storage() for the 0 case and store_by_pieces directly for any other values. Clearly something clear_storage() does is giving the optimizer the fits.
Oh that is not leaking. The real issue is that the memset is not removed at the tree level.
Related to bug 36602.
Jakub, for this example: how would you suggest to work around this warning?
It's now optimized by RTL DSE but we keep the stack allocated. Re-confirmed on the tree-level. Should be easy to extend DSE to handle this.
Related to this is struct X { int i; int j; int k; }; void foo (void) { struct X a, b; __builtin_memcpy (&a, &b, 4); } where we are unable to DCE the memcpy call. Both issues should be tackled at tree DCE level by better handling of aliased (local) variables. Needs the same infrastructure changes as PR41490.
Both cases compile down to simple returns at the tree level now. I did not bother to bisect precisely which changes are responsible for fixing this BZ.