[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled

["mpaton at swbell dot net" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073

Michael Paton <mpaton at swbell dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpaton at swbell dot net

--- Comment #6 from Michael Paton <mpaton at swbell dot net> 2013-01-15 17:02:31 UTC ---
I would like to question the resolution status of this bug.

Perhaps I will be educated on the process used here, but I fail to see how
supplying different source code fixes this bug. Making it go away, IMO is not
the same as fixing it.

The original code is likely not what the original author intended, and the
alternate code supplied by Richard Biener is by some measures "better".

However the original code is NOT invalid C code. It certainly reads memory past
the end of an array, and so assigns an undetermined value to the variable dd.
However this action is

1 Still valid C code
2 does not affect the control flow of the for loop in the code as written

Furthermore, the "endless loop" is in fact a jump to the current instruction,
with no sign of code for the accesses of arrays d and m.

While it is inconvenient for the optimizer to discover source code like this,
the optimizer is free to either not optimize, or complain via a diagnostic, or
in the extreme to refuse to compile. I do not believe it is free to silently
emit bad code in response to inconvenient, valid C ode.

I'd be happy to be educated on why the emitted code could be valid; currently I
do not see how it could be.