[Bug testsuite/115140] [15 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c excess errors after r15-579-ga9251ab3c91c8c

["tschwinge at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|powerpc64-linux-gnu,        |
                   |powerpc64le-linux-gnu,      |
                   |*-*-solaris2.11             |
              Build|powerpc64-linux-gnu,        |
                   |powerpc64le-linux-gnu,      |
                   |*-*-solaris2.11             |
                 CC|                            |tschwinge at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
             Target|powerpc64-linux-gnu,        |
                   |powerpc64le-linux-gnu,      |
                   |*-*-solaris2.11             |
   Last reconfirmed|                            |2024-05-24
     Ever confirmed|0                           |1

--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
So the PASS -> FAIL regressions are due to parloops (for '-O2') no longer
parallelizing the simple OpenACC 'kernels' construct at line 185 (and two
more):

    int x[N];
    #pragma acc kernels
    {
      for (int i = 0; i < N; ++i)
        x[i] = i * i;
    }

(In reply to Richard Biener from comment #1)
> Looks like a testsuite artifact?
> 
> volatile // TODO PR90488
> static int state = -1;
> 
> I've not looked as to why/how we are getting that to influence points-to
> solutions (note as we track also integers volatile on non-pointers can
> matter).

Yeah, it's not obvious to me how that 'state' variable would have such an
effect -- but I've not yet 'diff'ed the dumps.

On the other hand, it's highly likely that there is some relation, as no other
OpenACC 'kernels' test cases did regress.