On Fri, 9 Nov 2012 17:34:26 +0100, Jan wrote: > > I don't mind saying that GCC should define cases that the language > > standards leave undefined. But that does not seem to be what this > > patch does. I don't see why this is a good idea. It seems to > > produce a program that is unpredictable in a different way. How > > does that help the user? If anything an infinite loop might be > > better, since it is more obvious that something is wrong. Unless I > > misunderstand. > > I think resonable thing to do is to output warning in this case > "Loop reaches undefined effect before any of the exit conditions are > satisfied; turned into infinite loop" or something along these > lines? We can probably even get the location info of the statement > that implied the loop bound.
I had reckoned that the behaviour could be reverted to what was before while I figure out a way to get the warning in place for both cases, i.e. with tree-vrp (where max_loop_iterations now causes the loop to be folded away in -O2) and this unroll case (in -O1). I'll look at getting a warning for the tree-vrp case separately if the infinite loop behaviour needs to be retained. An infinite loop without the warning breaks diagnostic apps like valgrind since they are no longer in a position to detect this. The user would then have to somehow conclude that their loop loops infinitely because they have a beyond-array-bounds access in it. However, the infinite loop could be OK if there is an explicit warning telling the user that it's going to happen. I already have some rough code in place to do the warning against the loop header, so I'll clean it up to issue a warning for all exit points beyond the upper bound when we see that no exits remain. It will break a few existing test cases though - I had posted a patch to fix those earlier today: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00722.html Thanks, Siddhesh
