https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:d80aeff0bf2f455e9099def756f612bfbcd2cb0d commit r12-773-gd80aeff0bf2f455e9099def756f612bfbcd2cb0d Author: Jakub Jelinek <ja...@redhat.com> Date: Thu May 13 16:53:48 2021 +0200 openmp: Add testcases to verify OpenMP 5.0 2.14 and OpenMP 5.1 2.17 rules [PR99928] In preparation of PR99928 patch review, I've prepared testcases with clauses that need more interesting handling on combined/composite constructs, in particular firstprivate, lastprivate, firstprivate+lastprivate, linear (explicit on non-iv, explicit on simd iv, implicit on simd iv, implicit on simd iv declared in the construct), reduction (scalars, array sections of array variables, array sections with pointer bases) and in_reduction. OpenMP 5.0 had the wording broken for reduction, the intended rule to use map(tofrom:) on target when combined with it was bound only on inscan modifier presence which makes no sense, as then inscan may not be used, this has been fixed in 5.1 and I'm just assuming 5.1 wording for that. There are various cases where e.g. from historical or optimization reasons GCC slightly deviates from the rules, but in most cases it is something that shouldn't be really observable, e.g. whether #pragma omp parallel for firstprivate(x) is handled as #pragma omp parallel shared(x) #pragma omp for firstprivate(x) or #pragma omp parallel firstprivate(x) #pragma omp for shouldn't be possible to distinguish in user code. I've added FIXMEs in the testcases about that, but maybe we just should keep it as is (alternative would be to do it in standard compliant way and transform into whatever we like after gimplification (e.g. early during omplower)). Some cases we for historical reasons implement even with clauses on constructs which in the standard don't accept them that way and then handling those magically in omp lowering/expansion, in particular e.g. #pragma omp parallel for firstprivate(x) lastprivate(x) we treat as #pragma omp parallel firstprivate(x) lastprivate(x) #pragma omp for even when lastprivate is not valid on parallel. Maybe one day we could change that if we make sure we don't regress generated code quality. I've also found a bug in OpenMP 5.0/5.1, #pragma omp parallel sections firstprivate(x) lastprivate(x) incorrectly says that it should be handled as #pragma omp parallel firstprivate(x) #pragma omp sections lastprivate(x) which when written that way results in error; filed as https://github.com/OpenMP/spec/issues/2758 to be fixed in OpenMP 5.2. GCC handles it the way it used to do and users expect, so nothing to fix on the GCC side. Also, we don't support yet in_reduction clause on target construct, which means the -11.c testcase can't include any tests about in_reduction handling on all the composite constructs that include target. The work found two kinds of bugs on the GCC side, one is the known thing that we implement still the 4.5 behavior and don't mark for lastprivate/linear/reduction the list item as map(tofrom:) as mentioned in PR99928. These cases are xfailed in the tests. And another one is with r21 and r28 in -{8,9,10}.c tests - we don't add reduction clause on teams for #pragma omp {target ,}teams distribute simd reduction(+:r) even when the spec says that teams shouldn't receive reduction only when combined with loop construct. In make check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} gomp.exp=pr99928*' testing this shows: # of expected passes 5648 # of expected failures 872 and with Tobias' patch applied: # of expected passes 5648 # of unexpected successes 384 # of expected failures 488 2021-05-13 Jakub Jelinek <ja...@redhat.com> PR middle-end/99928 * c-c++-common/gomp/pr99928-1.c: New test. * c-c++-common/gomp/pr99928-2.c: New test. * c-c++-common/gomp/pr99928-3.c: New test. * c-c++-common/gomp/pr99928-4.c: New test. * c-c++-common/gomp/pr99928-5.c: New test. * c-c++-common/gomp/pr99928-6.c: New test. * c-c++-common/gomp/pr99928-7.c: New test. * c-c++-common/gomp/pr99928-8.c: New test. * c-c++-common/gomp/pr99928-9.c: New test. * c-c++-common/gomp/pr99928-10.c: New test. * c-c++-common/gomp/pr99928-11.c: New test.
