On Fri, 3 Apr 2020, Thomas Schwinge wrote:
> Hi!
>
> On 2020-04-02T11:12:48+0200, Richard Biener <rguent...@suse.de> wrote:
> > On Wed, 1 Apr 2020, Jason Merrill wrote:
> >
> >> On 4/1/20 9:36 AM, Richard Biener wrote:
> >> > This does away with enabling -ffinite-loops at -O2+ for all languages
> >> > and instead enables it selectively for C++ only.
>
> > I'm retesting the following [...]
>
> ..., which got pushed in commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae
> "c/94392 - only enable -ffinite-loops for C++".
>
> I pushed the attached in commit 4f6a0888de52a2e523a6fd4235fe7f8193819c3b
> 'Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713,
> PR94392]'. As can be observed in two nvptx offloading test cases
> regressing, 'apparently now again "empty oacc loops are" no longer
> "removed before expand"' (quoting myself from the commit log, adapting
> Tom's commit log snippet from the reverted commit).
>
> It's not obvious to me how the "finite loop" property discussed/changed
> in Richard's commit 75efe9cb1f8938a713ce540dc3b27bc2afcd3fae "c/94392 -
> only enable -ffinite-loops for C++" relates to the previously observed
> optimization of removing "empty oacc loops [...] before expand" (after
> PR89713 commit c29c92c789d93848cc1c929838771bfc68cb272c "PR
> tree-optimization/89713 - Assume loop with an exit is finite"), but
> examining that in detail is for another day.
For C we no longer have -ffinite-loops in effect but for C++ we still
do. But since the testcase is c/c++ common I'd have expected it
now fails "split" ... so an explicit -fno-finite-loops or
-ffinite-loops with an explanation would be easier.
Note there's now also the opportunity to set the loop flag for
OpenACC/OpenMP annotated loops if any of that guarantees finiteness.
(for GCC11 only please)
Richard.
