This is the mail archive of the 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/33498] [4.2/4.3 Regression] Optimizer (-O2) may convert a normal loop to infinite

------- 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

int i;
int some_int = 0;
for (i = 0 ; i < 100 ; i++) {
    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                     |

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