openmp: Add testcases to verify OpenMP 5.0 2.14 and OpenMP 5.1 2.17 rules [PR99928]

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  <jakub@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.