* [Bug c/94392] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
@ 2020-03-29 21:22 ` pinskia at gcc dot gnu.org
2020-03-30 8:21 ` [Bug c/94392] [10 Regression] " rguenth at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-03-29 21:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
2020-03-29 21:22 ` [Bug c/94392] " pinskia at gcc dot gnu.org
@ 2020-03-30 8:21 ` rguenth at gcc dot gnu.org
2020-03-30 23:36 ` joseph at codesourcery dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-30 8:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
2020-03-29 21:22 ` [Bug c/94392] " pinskia at gcc dot gnu.org
2020-03-30 8:21 ` [Bug c/94392] [10 Regression] " rguenth at gcc dot gnu.org
@ 2020-03-30 23:36 ` joseph at codesourcery dot com
2020-03-31 6:34 ` rguenther at suse dot de
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: joseph at codesourcery dot com @ 2020-03-30 23:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
` (2 preceding siblings ...)
2020-03-30 23:36 ` joseph at codesourcery dot com
@ 2020-03-31 6:34 ` rguenther at suse dot de
2020-04-01 7:44 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenther at suse dot de @ 2020-03-31 6:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
` (3 preceding siblings ...)
2020-03-31 6:34 ` rguenther at suse dot de
@ 2020-04-01 7:44 ` rguenth at gcc dot gnu.org
2020-04-02 14:53 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-04-01 7:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
` (4 preceding siblings ...)
2020-04-01 7:44 ` rguenth at gcc dot gnu.org
@ 2020-04-02 14:53 ` cvs-commit at gcc dot gnu.org
2020-04-02 14:54 ` rguenth at gcc dot gnu.org
2020-04-03 8:10 ` cvs-commit at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-02 14:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
` (5 preceding siblings ...)
2020-04-02 14:53 ` cvs-commit at gcc dot gnu.org
@ 2020-04-02 14:54 ` rguenth at gcc dot gnu.org
2020-04-03 8:10 ` cvs-commit at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-04-02 14:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/94392] [10 Regression] Infinite loops are optimized away for C99
2020-03-29 21:13 [Bug c/94392] New: Infinite loops are optimized away for C99 krister.walfridsson at gmail dot com
` (6 preceding siblings ...)
2020-04-02 14:54 ` rguenth at gcc dot gnu.org
@ 2020-04-03 8:10 ` cvs-commit at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-03 8:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread