[Patch] OpenMP: Support acquires/release in 'omp require atomic_default_mem_order'
Jakub Jelinek
jakub@redhat.com
Fri Dec 8 13:47:41 GMT 2023
On Tue, Nov 28, 2023 at 12:28:05PM +0100, Tobias Burnus wrote:
> I stumbled over this omission when looking at Sandra's patch. It turned out that this is
> a new OpenMP 5.2 feature - probably added to simplify/unify the syntax. I guess the reason
> that release/acquire wasn't added before is that it cannot be universally be used - read/write
> do only accept one of them.
I thought when this was discussed that it was meant to behave right (choose
some more appropriate memory model if one was not allowed), but reading 5.2
I think that is not what ended up in the spec, because [213:11-13] says that
atomic_default_mem_order is as if the argument appeared on any atomic
directive without explicit mem-order clause and atomic directive has the
[314:9-10] restrictions.
I'd bring this to omp-lang whether it was really meant that
#pragma omp requires atomic_default_mem_order (release)
int foo (int *p) {
int t;
#pragma omp atomic read
t = *p;
return t;
}
and
#pragma omp requires atomic_default_mem_order (acquire)
void bar (int *p) {
#pragma omp atomic write
*p = 0;
}
are meant to be invalid.
Another comment, atomic_default_mem_order arguments aren't handled
just in the requires parsing, but also in context selectors.
So, the additions would need to be reflected in
omp_check_context_selector and omp_context_selector_matches
as well.
Jakub
More information about the Fortran
mailing list