[Bug c/103385] New: [OpenMP] reduction(+: temp[0], temp[1]) rejected with 'appears more than once'

[Bug c/103385] New: [OpenMP] reduction(+: temp[0], temp[1]) rejected with 'appears more than once'

[burnus at gcc dot gnu.org]

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

            Bug ID: 103385
           Summary: [OpenMP] reduction(+: temp[0], temp[1]) rejected with
                    'appears more than once'
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: openmp, rejects-valid
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Found via
https://github.com/SOLLVE/sollve_vv/blob/ae54ca3b15a7820125175a1ac478235d20a286b5/tests/5.0/parallel_reduction/test_parallel_reduction_multiple_array_elements.c
(of Pull Request 362)

Ignoring the odd expectation in the linked testcase that there is only a single
thread (and thus expecting temps[0] == 1), it seems as if

  static double temps[2];
...
  #pragma omp parallel reduction(+:temps[0], temps[1])
    {
      temps[0] += 1;
      temps[1] += 1;
    }

is valid. Still, GCC rejects it with

  error: ‘temps’ appears more than once in data clauses


At least, the OpenMP specification has the restriction (in OpenMP 5.2, "5.5.5
Properties Common to All Reduction Clauses", [132:11-16]):

Restrictions common to reduction clauses are as follows:
• Any array element must be specified at most once in all list items on a
directive.
[...]
• If a list item is an array section, it must specify contiguous storage, it
cannot be
  a zero-length array section and its base expression must be a base language
identifier.

The first bullet implies that 'temp' can appear multiple times – only the
element 0 and 1 may only appear once.

[Bug c/103385] [OpenMP] reduction(+: temp[0], temp[1]) rejected with 'appears more than once'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No, IMNSHO this is invalid.
reduction is a privatization clause, and one can't privatize two elements of
the same variable separately.  It is valid to do #pragma omp parallel
reduction(+:temps[:2]), but not reduction(+:temps[0], temps[1])

[Bug c/103385] [OpenMP] reduction(+: temp[0], temp[1]) rejected with 'appears more than once'

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
To expand on this, reduction(+:temps[0]) is handled by creating private double
temps_priv[1]; variable and arranging for temps to be remapped to
*&temps_priv[0].  Only temps[0] or &temps[1] can be accessed safely in that
case.
reduction(+:temps[1]) is handled by creating private double temps_priv2[1];
variable and arranging for temps to be remapped to *(&temps_priv2[0] - 1)
(which is not valid C/C++, but compiler can of course do it).  Only temps[1] or
&temps[2] can be accessed safely in that case.
But, if you privatize both, what will temps become?

We do have exceptions that one can privatize in methods the non-static data
members of the current class but have restrictions that one can't access those
through this->member, but only member, so member1 and member2 are then
privatized separately.  That is not what we have for this case.