https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122517
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |parras at gcc dot gnu.org
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #2)
> Additionally, I wonder whether
> gimple_build_omp_interop / GIMPLE_OMP_INTEROP
> shouldn't be removed for good and the code of omp-low.cc's lower_omp_interop
> just be moved into gimplify_scan_omp_clauses.
> After all, there is no associated code – but just a function call generated.
I wonder how to handle this properly, given that we have in omp-low.cc:
error_at (gimple_location (stmt),
"OpenMP constructs other than %<parallel%>, %<loop%>"
" or %<simd%> may not be nested inside a region with"
" the %<order(concurrent)%> clause");
Everything that gets converted too early into some function call might be
missed; while 'omp dispatch' might be still kind of okay, 'omp taskwait',
'omp flush', 'omp interop depend(…)' et probably shouldn't.
* * *
Side remark: 'omp flush' is not diagnosed (which is converted to
__sync_synchronize), but the others (currently) are:
void f() {
#pragma omp parallel for order(concurrent)
for (int i=0; i < 10; i++)
{
#pragma omp flush
}
}
I wonder whether we need a kind of marker, similar to OMP_STRUCTURED_BLOCK /
GOMP_STRUCTURED_BLOCK, for those – whose only purpose is to handle such
diagnostic and that can be removed for good in omp-low.cc after the diagnostic.
