[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 39524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39524&action=edit
gcc7-pr65467-wip.patch

Untested WIP patch.  This attempts to handle _Atomic qualified vars/expressions
etc. where it is easy and non-controversial, and error out otherwise.
Testsuite coverage for the rejections is still missing.
The cases I plan to (in the current patch or later) reject are:
1) omp loop iterators (for, simd, distribute, taskloop) - I think it makes
little sense to support that, and would be a nightmare to support
2) _Atomic vars in linear clause (again, little sense, not that hard to
support, but right now looks like wasted time to do until omp-lang decides)
3) _Atomic vars in reduction clause and _Atomic types in omp declare reduction
(again, little sense to do that, and quite a lot of work to support)
4) _Atomic vars in aligned clause (it is fine if it is in alignment expression)
5) _Atomic x expression in #pragma omp atomic (v or expr can be _Atomic)
6) _Atomic return type on omp declare simd functions, or _Atomic arguments
unless they are uniform (again, not impossible to handle, but lots of work and
little sense) - this isn't rejected, but just warned and declare simd ignored
7) _Atomic vars in explicit map/to/from clauses (this a nightmare to support,
right now the runtime library doesn't have support to run special functions to
copy the data to/from, it is similar to not actually running ctors/dtors, but
just doing memcpy-ish transfers; and it isn't just the host <-> device
transfers, but also possible copying into a temporary for target nowait
Not in the patch yet:
8) reject implicit map clauses for _Atomic vars
9) reject firstprivate on _Atomic vars on the target construct (not as hard as
map, but also very complicated)