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

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

[izamyatin at gmail dot com]

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

             Bug #: 53128
           Summary: [4.8 Regression] Compiler produces infinite loop on
                    regular O2
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: izamyatin@gmail.com
            Target: x86-64


Created attachment 27247
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27247
Testcase

After the fix for PR53031 (revision 186592) compiler at O2 generates infinite
loop for the attached testcase attached.

Rev 186591 generates normal code...

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-04-26
     Ever Confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-26 15:57:23 UTC ---
Please provide a run-time testcase.

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

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |amonakov at gcc dot
                   |                            |gnu.org, rguenth at gcc dot
                   |                            |gnu.org
         Resolution|                            |INVALID

--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> 2012-04-26 16:20:39 UTC ---
The code invokes undefined behavior as the increment statement of the outer
loop tries to access ss[tt].a1[14] at the last iteration.  GCC optimizes out
the loop exit test due to recent changes by Richard Guenther.

Richard, I think a warning here would be very helpful (I remember you mentioned
that in IRC too).  What would implementing such a warning involve?

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

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> 2012-04-27 08:02:39 UTC ---
On Thu, 26 Apr 2012, amonakov at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53128
> 
> Alexander Monakov <amonakov at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|WAITING                     |RESOLVED
>                  CC|                            |amonakov at gcc dot
>                    |                            |gnu.org, rguenth at gcc dot
>                    |                            |gnu.org
>          Resolution|                            |INVALID
> 
> --- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> 2012-04-26 16:20:39 UTC ---
> The code invokes undefined behavior as the increment statement of the outer
> loop tries to access ss[tt].a1[14] at the last iteration.  GCC optimizes out
> the loop exit test due to recent changes by Richard Guenther.
> 
> Richard, I think a warning here would be very helpful (I remember you mentioned
> that in IRC too).  What would implementing such a warning involve?

It's very difficult to warn for this as at the point we use the 
information to optimize the loop exit test we do not know where it came
from.  Thus, apart from warning on every exit test we optimize that
way (with the obvious false positives and the fact the warning would
be very unspecific "warning: optimized loop exit test") I see no way
of warning here.

Other loop optimizations also can take advantage of this fact without
knowing.

Richard.

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

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin <izamyatin at gmail dot com> 2012-05-03 11:09:15 UTC ---
Isn't it too aggressive from user perspective to perform such transformation
even without warning? Especially for the case when that "wrong" read is not
used later.
Sure it is dangerous anyway to make such access but at he same time it seems
this could affect lot of existing code...

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-03 16:02:56 UTC ---
(In reply to comment #4)
> Isn't it too aggressive from user perspective to perform such transformation
> even without warning? Especially for the case when that "wrong" read is not
> used later.
> Sure it is dangerous anyway to make such access but at he same time it seems
> this could affect lot of existing code...

Igor, I guess the compiler only sees something like:

x = 14
if (x < 13) do_A(); else do_B();

and transform it into:

do_A();

It doesn't see that an infinite loop is generated. Now, whether there could be
an optimization pass that detects infinite loops, and warns for them, that I am
not sure, but surely it would be a nice thing to have. If someone contributed a
nice implementation, I think it will be accepted. Unfortunately, I don't think
it is in the TODO list of any current contributor.

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

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin <izamyatin at gmail dot com> 2012-05-04 13:19:07 UTC ---
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.

Again, I'm worrying about all this from user-perspective and especially after
discovering 2 such things in spec2006 sources(PR53086 and PR53073).

Interesting, could people have problems with SPEC results reporting since they
have to modify sources for this?

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

[manu at gcc dot gnu.org]

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.

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

[rguenther at suse dot de]

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?

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

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov <amonakov at gcc dot gnu.org> 2012-05-07 14:07:58 UTC ---
I have opened PR 53265