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

[mpaton at swbell dot net]

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



Michael Paton  changed:



   What|Removed |Added



 CC||mpaton at swbell dot net



--- Comment #6 from Michael Paton  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.

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

[mpaton at swbell dot net]

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



--- Comment #8 from Michael Paton  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  changed:

> 

>What|Removed |Added

> 

>  CC||jakub at gcc dot gnu.org

> 

> --- Comment #7 from Jakub Jelinek  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.

>