[Bug c/94392] New: Infinite loops are optimized away for C99

[Bug c/94392] New: Infinite loops are optimized away for C99

[krister.walfridsson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

            Bug ID: 94392
           Summary: Infinite loops are optimized away for C99
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: krister.walfridsson at gmail dot com
  Target Milestone: ---

Created attachment 48141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48141&action=edit
Source code reproducing the issue

John Regehr noticed on twitter
(https://twitter.com/johnregehr/status/1244335355509129216) that trunk GCC
removes infinite loops for C99, as can be seen by
  gcc -O3 -std=c99 fermat.c

This behavior was introduced by the introduction of -ffinite-loops being
enabled at -O2. This is fine for C11, but infinite loops do not invoke
undefined behavior in C99, so the optimization should not be enabled per
default for -std=c99.

[Bug c/94392] Infinite loops are optimized away for C99

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I was looking at the patch email thread and the issue of finiteness not being
discussed.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Infinite loops are          |[10 Regression] Infinite
                   |optimized away for C99      |loops are optimized away
                   |                            |for C99
   Target Milestone|---                         |10.0
                 CC|                            |jsm28 at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Infinite loops do not make much sense so the consensus was to enable it
everywhere by default (also for non-C/C++ languages).

Joseph, any opinion whether we should make the default language (standard)
dependent?  It'll be tracked per function with LTO but inlining currently
does not care about caller/callees state difference.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I'm not sure the existing infinite loop removal is valid for any C 
standard version.  The C (C11 and later) rule against infinite loops only 
applies when the loop is written as an iteration statement whose 
controlling expression is not constant (not if it's written with goto, or 
has a constant controlling expression); it's not the more general rule 
about forward progress that C++ has.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 30 Mar 2020, joseph at codesourcery dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392
> 
> --- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
> I'm not sure the existing infinite loop removal is valid for any C 
> standard version.  The C (C11 and later) rule against infinite loops only 
> applies when the loop is written as an iteration statement whose 
> controlling expression is not constant (not if it's written with goto, or 
> has a constant controlling expression); it's not the more general rule 
> about forward progress that C++ has.

For the middle-end feature we need to define what loops we consider
finite in middle-end terms which currently is that the loop has
at least one "normal" (non-EH, non-abnormal) exit.  In that case
the middle-end assumes the loop will eventually terminate.  That
in particular means if the middle-end removes all exits as unreachable
then the loop will no longer appear finite.  I think the middle-end
never introduces additional normal exits so any loop that did not
contain an exit at the source AST level should never appear finite.

So iff the C rule forbids while (a) {} to be infinite but does
_not_ forbid while (1) {} to be infinite this is in-line with
the middle-end implementation.  I _think_ the C++ standard disallows
while (1) {}, too.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |ASSIGNED
           Keywords|                            |wrong-code
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-04-01

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Nice testcase btw ;)  I think to fix it you simply need to add an exit when
the search space is exhausted, thus when c > MAX do not reset it but return 0.

I understand that the while (1) { } style loop doesn't fall under the
"iteration statement whose controlling expression is not constant"
case.

Encoding this in the IL (struct loop) would be nice - we would need to
add a finite_p flag (so loosing it on the way only creates missed
optimizations,
not wrong-code) and populate that via either the existing ANNOTATE_EXPR
machinery or some langhook (note this would be queried after CFG build and thus
after IL lowering which might be too late for FEs to recover the original
loop construct).

Confirmed and mine.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:75efe9cb1f8938a713ce540dc3b27bc2afcd3fae

commit r10-7522-g75efe9cb1f8938a713ce540dc3b27bc2afcd3fae
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Apr 2 10:46:20 2020 +0200

    c/94392 - only enable -ffinite-loops for C++

    This does away with enabling -ffinite-loops at -O2+ for all languages
    and instead enables it selectively for C++ only.

    It also makes -ffinite-loops loop-private at CFG construction time
    fixing correctness issues with inlining.

    2020-04-02  Richard Biener  <rguenther@suse.de>

            PR c/94392
            * c-opts.c (c_common_post_options): Enable -ffinite-loops
            for -O2 and C++11 or newer.

            * common.opt (ffinite-loops): Initialize to zero.
            * opts.c (default_options_table): Remove OPT_ffinite_loops
            entry.
            * cfgloop.h (loop::finite_p): New member.
            * cfgloopmanip.c (copy_loop_info): Copy finite_p.
            * ipa-icf-gimple.c (func_checker::compare_loops): Compare
            finite_p.
            * lto-streamer-in.c (input_cfg): Stream finite_p.
            * lto-streamer-out.c (output_cfg): Likewise.
            * tree-cfg.c (replace_loop_annotate): Initialize finite_p
            from flag_finite_loops at CFG build time.
            * tree-ssa-loop-niter.c (finite_loop_p): Check the loops
            finite_p flag instead of flag_finite_loops.
            * doc/invoke.texi (ffinite-loops): Adjust documentation of
            default setting.

            * gcc.dg/torture/pr94392.c: New testcase.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:2b1e849b35bfe694b09f090397944e11c9f1dc04

commit r10-7532-g2b1e849b35bfe694b09f090397944e11c9f1dc04
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Fri Apr 3 10:08:59 2020 +0200

    Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713,
PR94392]

    In response to PR94392 commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae
    "c/94392 - only enable -ffinite-loops for C++", this reverts PR89713
    commit 00908992f2a78f213d227aea8dbab014a1361df0, as apparently now again
    "empty oacc loops are" no longer "removed before expand".

            libgomp/
            PR tree-optimization/89713
            PR c/94392
            * testsuite/libgomp.oacc-c-c++-common/pr85381-2.c: Again expect
            'bar.sync'.
            * testsuite/libgomp.oacc-c-c++-common/pr85381-4.c: Likewise.