[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> 2012-05-07 08:43:24 UTC ---
On Fri, 4 May 2012, manu at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53128
> 
> --- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-04 16:15:09 UTC ---
> (In reply to comment #6)
> > Compiler does not simply see such code, it happens after some analysis, right?
> > For example, after work of infer_loop_bounds_from_undefined which makes some
> > assumptions and I believe can produce some information for user.
> 
> My understanding is that this is non-trivial to do from within the current
> passes because "undefined" in that context does not mean "this code is wrong"
> but "we don't know what happens here but we can assume what doesn't happen". So
> perhaps a new pass looking specifically for infinite loops could be more
> effective.
> 
> In any case, if you know how to do it, please propose a patch, so people can
> discuss it. If there is way to warn for this that doesn't generate an awful
> number of false positives, I think such patch would be very welcome.
> 
> > Again, I'm worrying about all this from user-perspective and especially after
> > discovering 2 such things in spec2006 sources(PR53086 and PR53073).
> 
> I think there is no discussion about whether GCC would like to have such a
> warning. What is not clear is the best way to do it. So please, test your ideas
> and send a prototype of your patch for discussion. People are more likely to
> give you feedback when there is something concrete to discuss about.

One reason I am not trying hard to avoid these issues at the very moment
is to look for _real_ fallout - thus, wrong-code generation on valid
input.  One option for the 4.8 release is to simply never fold the
("the" - if there is a single one) loop exit test to false from within
VRP.  That does not prevent other passes from eventually generating
code that runs afoul of users expectations (with the bogus input),
but at least the "issues at hand" would be mitigated.

Note that this of course would prevent

  int i;
  for (i = 5; i != 1; ++i)
    ...

from being folded into an infinite loop, too, which happens since
quite some GCC releases (based on undefined signed overflow).  And of
course "deliberate" infinite loops would be less optimized as they
would retain a useless exit comparison.

Not sure if people would like to live with a warning for every
loop exit test that is computed to be always false though.

Btw, can you please open an enhacement bugreport for all of this?