https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245
--- Comment #4 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> The difference between r227381 and r227382 on the testcase is:
> --- r227382-1.s1 2016-03-15 20:34:52.699640513 +0100
> +++ r227382-1.s2 2016-03-15 20:35:05.278470114 +0100
> @@ -116,7 +116,7 @@ _ZL3barP1BPi:
> movl 24(%esp), %edi
> movl %eax, 24(%esp)
> movl %edi, 12(%esp)
> - movl (%edx), %ecx
> + movl (%edi), %ecx
> movl %eax, (%esp)
> addl %edx, %ecx
> movl %ebp, 4(%esp)
> which is the load of g->d in d's arguments, %edi at this point isn't equal
> to g, while %edx is (you can see it a few insns later, g and f are not
> modified after assignment and aren't addressable, thus they have the same
> value, and so it is actually f + f->d, in the addition it is either correct
> %edx + (%edx), or incorrect %edx + (%edi) where %edi happens to point to 0
> instead of the right 4.
I see in peephole a wrong transformation:
190: cx:SI=dx:SI
REG_DEAD dx:SI
95: {cx:SI=cx:SI+[cx:SI];clobber flags:CC;}
into
242: cx:SI=[cx:SI]
243: {cx:SI=cx:SI+dx:SI;clobber flags:CC;}
