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

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

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

--- Comment #8 from Michael Paton <mpaton at swbell dot net> 2013-01-15 20:01:04 UTC ---
Hopefully it's correct to reply to the mailing list rather than to bugzilla.
I've tried to find definitive guidance on that and failed.

Thanks for your informative reply asserting C99 non compliance. My assertion on
validity was C89 based, but let's use yours and move on.

I accept that the source code in #c2 is invalid C99 code, and that undefined
behavior may be the result.

However, I will still argue that undefined behavior should be a diagnostic, or
a
lack of an optimizing transformation. If the compiler is to be silent on
discovering this invalid C code, I do not believe it should go on to produce
code that runs until it starts executing an infinite loop.

While that may be allowed by ISO C99, I have a hard time believing that it is
useful to the users of gcc, or indeed intended by its contributors. This
invalid
code compiles and executes with -O0, yet generates bad assembly code ending in
an infinite loop with -O2. I think this is indicative of a bug in gcc 4.8.0. As
to whether such a bug might influence valid code, I cannot say.

Michael Paton

On 1/15/2013 11:56 AM, jakub at gcc dot gnu.org wrote:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-15 17:56:05 UTC ---
> You're wrong, the code in #c2 is not valid C.
> ISO C99 6.5.2.1 says that d[++k] is equivalent to:
>   (*((d)+(++k)))
> and ++k in the last iteration is 16, so it is
>   (*(d+16))
> and then 6.5.6/8 (last sentence) applies:
> "If the result points one past the last element of the array object, it
> shall not be used as the operand of a unary * operator that is evaluated."
> So, if you ever enter this loop, you'll invoke undefined behavior and anything
> can happen.
>