[Bug c/105536] New: [OpenMP] Bogus "expected ‘concurrent’ before ‘reproducible’"

[Bug c/105536] New: [OpenMP] Bogus "expected ‘concurrent’ before ‘reproducible’"

[burnus at gcc dot gnu.org]

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

            Bug ID: 105536
           Summary: [OpenMP] Bogus "expected ‘concurrent’ before
                    ‘reproducible’"
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: diagnostic, openmp
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I think the message shown by C/C++ for the following is bogus:

repro.c:3:23: error: expected ‘concurrent’ before ‘reproducible’
    3 | #pragma omp for order(reproducible)
      |                       ^~~~~~~~~~~~

The standard requires 'order(reproducible:concurrent)' – Thus, I expect *after*
and not *before* in the error message.
Cf. https://www.openmp.org/spec-html/5.1/openmpsu47.html#x72-720002.11.3

void f(void)
{
#pragma omp for order(reproducible)
 for (int i=0; i < 1; i++)
   ;
}


Side remark: Fortran is fine as it gives the following:

    1 | !$omp do order(reproducible)
      |                1
Error: Expected ORDER(CONCURRENT) at (1) with optional ‘reproducible’ or
‘unconstrained’ modifier

[Bug c/105536] [OpenMP] Bogus "expected ‘concurrent’ before ‘reproducible’"

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The issue occurred at real-world code (sollve_vv testcase before it was fixed).

The issue is because of:
   if (c_parser_next_token_is (parser, CPP_NAME)
      && c_parser_peek_2nd_token (parser)->type == CPP_COLON)
/* ... Parse reproducible/unconstrained ... */

  p = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
  if (strcmp (p, "concurrent") != 0)
    {
      c_parser_error (parser, "expected %<concurrent%>");
      goto out_err;
    }

And the error message is then 'expected concurrent'
   + auto-added "before <what comes instead>"

That message is fine – except for this specific case it is somewhat misleading.

→ The question is whether we want to handle this in a different way
  (yield better error message, how?)
  OR – whether that's just too specific and close this PR as WONTFIX?