This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/33498] [4.2/4.3 Regression] Optimizer (-O2) may convert a normal loop to infinite
- From: "dada1 at cosmosbay dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Sep 2007 08:17:26 -0000
- Subject: [Bug tree-optimization/33498] [4.2/4.3 Regression] Optimizer (-O2) may convert a normal loop to infinite
- References: <bug-33498-15115@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #10 from dada1 at cosmosbay dot com 2007-09-20 08:17 -------
>
> What happens is that ivopts decide to use val as the variable to use in the
> exit compare; they compute what its final value will be (67305984), and replace
> the exit test by val != 67305984.
>
> There is not much I can do with that in ivopts. I could make ivopts avoid
> preserving signed variables appearing in the source code that provably
> overflow; but I do not think we want to introduce this kind of hacks to handle
> code with undefined behavior.
>
This code is valid. Integer overflows of a counter may happen in any program.
i = 0x7fffffff,
i += 1; /* IS VALID */
/* Here, gcc-4.1.2 can emit some infinite loop because programmer is lazy ! */
At very least, gcc should emit a BIG WARNING or ERROR
The integer overflow is not a excuse for a compiler to generate an infinite
loop.
int i;
int some_int = 0;
for (i = 0 ; i < 100 ; i++) {
some_func(some_int);
some_int += 0x40000000; /* yes, it can 'overflow'... big deal */
}
Are you telling me that *any* integer overflow allows a compiler to generate a
buggy code without any notice ? Interesting.
--
dada1 at cosmosbay dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498