This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
- From: "mikpelinux at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 15 Oct 2013 13:36:01 +0000
- Subject: [Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3
- Auto-submitted: auto-generated
- References: <bug-58143-4 at http dot gcc dot gnu dot org/bugzilla/>
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.