This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3


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

--- Comment #26 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Bernd Edlinger from comment #24)
> Wall,
> 
> the logic behind the loop niter is really strange
> and the results are simply insane.
> 
> When you consider this example:
> 
> int a, b, c, d, e;
> 
> int
> main ()
> {
>   for (b = 4; b > -30; b--)
>     {
>     e = 2147483647 - b;
>     for (; c;)
>       for (;;)
>         {
>           if (d)
>             break;
>         }
>     }
>   return 0;
> }
> 
> then the reasoning is that an "undefined" value will
> be written to e in loop iteration #4.
> And therefore it does not matter what happens afterwards.
> But for the result of main() which will ultimately be 0
> the undefined value of e does not matter.
> 
> Why should a undefined value that is not used for anything
> create such a problem?

To re-emphasize what Richard wrote: it's undefined BEHAVIOUR not VALUE.  The
mere fact of causing undefined behaviour voids all guarantees about the future
behaviour of that process.  That the variable "e" above is unused is
immaterial.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]