[Bug c++/113581] New: Ignoring GCC unroll loop annotation for loops with increment in condition

[Bug c++/113581] New: Ignoring GCC unroll loop annotation for loops with increment in condition

[janschultke at googlemail dot com]

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

            Bug ID: 113581
           Summary: Ignoring GCC unroll loop annotation for loops with
                    increment in condition
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: janschultke at googlemail dot com
  Target Milestone: ---

Code to reproduce (https://godbolt.org/z/r6EcW7ocW)
===================================================

template <typename T>
int times_three(T x) {
    int sum = 0;
    #pragma GCC unroll 16
    for (int i = 0; i++ < 3;) {
        sum += x;
    }
    return sum;
}

int main() {
    times_three(123u);
}

Output
======

> <source>: In function 'int times_three(T) [with T = unsigned int]':
> <source>:5:19: warning: ignoring loop annotation
>     5 |     for (int i = 0; i++ < 3;) {
>       |                   ^


Explanation
===========

It looks like GCC doesn't like loops that have an increment in the condition.
Changing the loop to the following solves this issue:

> for (int i = 0; i < 3; i++)

For increment, this is perhaps not a big deal. I've run into this bug when
working with a loop of the form:

> for (int i = N; i-- > N;)

This is a popular idiom for decrementing with i in range [0, N).

[Bug c++/113581] Ignoring GCC unroll loop annotation for loops with increment in condition

[janschultke at googlemail dot com]

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

--- Comment #1 from Jan Schultke <janschultke at googlemail dot com> ---
Oh, I probably should have mentioned this: This only happens when times_three
is a function template.

[Bug c++/113581] Ignoring GCC unroll loop annotation for loops with increment in condition

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-24
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  The reason is we're seeing

<bb 4> :
i.2_3 = i;
i = i.2_3 + 1;
_4 = i.2_3 <= 2;
D.2811 = .ANNOTATE (_4, 1, 16);
retval.1 = D.2811;
if (retval.1 != 0)
  goto <bb 3>; [INV]
else
  goto <bb 5>; [INV]

and the .ANNOTATE is not directly peceeding the condition but the assign
is in the way.

The FE generates

    if (<<cleanup_point ANNOTATE_EXPR <i++  <= 2, unroll 16>>>) goto <D.2807>;
else goto <D.2805>;

for some reason this forces an extra temporary via voidify_wrapper_expr ()
during gimplification.

Possibly the frontend simply lacks knowledge of ANNOTATE_EXPR when
checking whether it needs this cleanup_point at all (but I see
it's too simplistic, checking for side-effects only).

We could walk simple assigns like those of course, but the extra
temporary looks superfluous.