https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92672
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I don't think this testcase is valid, because there is no guarantee the explicit task will not be an included task (just try OMP_NUM_THREADS=1 to force it, but there are many reasons why the implementation might choose to make the task included and the program has no control over that). And when the task is included, this violates the: "A simple lock accessed by omp_set_lock that is in the locked state must not be owned by the task that contains the call or deadlock will result." constraint. That said, I'm afraid one could change it into a conforming one by using e.g. nested locks and omp_get_thread_num or threadprivate var to detect the case when the task is actually run by the same thread as the single body and do something different in that case. GCC performs a shared -> firstprivate optimization for non-addressable small scalar variables that can't be modified in the region, see PR68128. I'm afraid your testcase if turned into a valid one would mean we can't use that optimization for task/taskloop. Admittedly the optimization is probably much more important for parallel or teams, because the usual default there is shared mapping, while for tasks they would be implicitly firstprivate.
