https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #2) > Guess the second condition should be !c->capture. I concur. > Now, something I have clearly missed in the review, why is capture not part > of atomic_op? capture is atomic-clause like the others. Because of preparation/anticipation for OpenMP 5.1 (TR9), which has: * atomic-clause is one of the following: read, write, update * memory-order-clause is one of the following: seq_cst, acq_rel, release, acquire, relaxed * clause is either atomic-clause, memory-order-clause or one of the following: capture, compare, hint(hint-expression), fail(seq_cst | acquire | relaxed), weak With: * If atomic-clause is not present on the construct, the behavior is as if the update clause is specified. * If a capture or compare clause appears on the construct then atomic-clause must be update. > And I'd be afraid we'd allow something like !$omp atomic capture update or > !$omp atomic update capture by making it separate. Which is intended (for OpenMP 5.1). I did loop at OpenMP 5.0 + 5.1 and OpenACC 2.6 + 3.0, but I admittedly missed that 'capture' could not occur with 'update' in OpenMP 5.0, also because the previous code was used for OpenACC, which does permit 'update capture' besides 'capture' (since OpenACC 2.5).
