Do you think you could produce a smaller, stand-alone testcase that reproduces the issue? Or at least attach the preprocessed sources to the report?

Created attachment 40076 [details]
simple test case

Compile with: gcc -o test test.c

This is a simple echo server. It *should* echo whatever the client types.  However, if you type "foo" the first time and then type ctrl-d the second time, the second reply is the same as the first reply. This is because the buffer was not properly zeroed.

Created attachment 40077 [details]
output assembly from the test case

This assembly was produced with: gcc -S test.c.

Confirmed. Trunk is fine.

--- good        2016-11-17 21:45:22.671247332 +0100
+++ bad 2016-11-17 21:45:18.851324283 +0100
@@ -58,11 +58,6 @@
        call    write
        testq   %rax, %rax
        jle     .L10
-       leaq    -65536(%rbp), %rax
-       movl    $65520, %edx
-       movl    $0, %esi
-       movq    %rax, %rdi
-       call    memset
        leaq    -131056(%rbp), %rax
        leaq    -65536(%rbp), %rcx
        movl    $65520, %edx
@@ -86,5 +81,5 @@
        .cfi_endproc
 .LFE0:
        .size   main, .-main
-       .ident  "GCC: (GNU) 7.0.0 20161117 (experimental)"
+       .ident  "GCC: (GNU) 6.2.1 20161017"
        .section        .note.GNU-stack,"",@progbits

This has nothing to do with "aggressive optimization" it is a bug in C front-end, I guess in the "loop initial declarations" implementation.

I don't think this is related to the loop, a = b = (struct buf) {} loses the assignment to b even if you put it alone on its line.

I can't reproduce this with recent GCC 6 branch.  Possibly a duplicate of 
bug 72747?

(In reply to joseph@codesourcery.com from comment #7)
> I can't reproduce this with recent GCC 6 branch.  Possibly a duplicate of 
> bug 72747?

Yes.

*** This bug has been marked as a duplicate of bug 72747 ***

Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
significantly more efficient code than a = b = (struct buf) {} - the former
is 2x memset, the latter 1x memset + 1x memcpy.
So, shall we for large aggregates gimplify those differently as an optimization?

(In reply to Jakub Jelinek from comment #9)
> Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
> significantly more efficient code than a = b = (struct buf) {} - the former
> is 2x memset, the latter 1x memset + 1x memcpy.
> So, shall we for large aggregates gimplify those differently as an
> optimization?

I believe the gimplifier is not a good place to do optimization.  You can
pattern-match

  memset (&a, ..., N);
  memcpy (&b, &a, N);

and transform it to two times memset.

(In reply to Richard Biener from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
> > significantly more efficient code than a = b = (struct buf) {} - the former
> > is 2x memset, the latter 1x memset + 1x memcpy.
> > So, shall we for large aggregates gimplify those differently as an
> > optimization?
> 
> I believe the gimplifier is not a good place to do optimization.  You can
> pattern-match
> 
>   memset (&a, ..., N);
>   memcpy (&b, &a, N);
> 
> and transform it to two times memset.

Even the *.optimized dump contains:
  b = {};
  a = b;
  d = {};
  c = d;
Can match.pd handle these, or would it need to be special folding code (where?  gimple-fold.c, tree dse, what other passes have good framework for that)?

Author: jakub
Date: Fri Dec 16 15:57:43 2016
New Revision: 243753

URL: https://gcc.gnu.org/viewcvs?rev=243753&root=gcc&view=rev
Log:
	PR c/78408
	* tree-ssa-ccp.c: Include tree-dfa.h.
	(optimize_memcpy): New function.
	(pass_fold_builtins::execute): Use it.  Remove useless conditional
	break after BUILT_IN_VA_*.

	* gcc.dg/pr78408-1.c: New test.
	* gcc.dg/pr78408-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr78408-1.c
    trunk/gcc/testsuite/gcc.dg/pr78408-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/sanopt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-ccp.c