Whether opening a thread team here would build the shape libgomp deadlocks on.
.true. when a region encloses this call (omp_get_level() > 0) but its team has one thread
(omp_get_active_level() == 0). libgomp (gfortran 15.2, macOS arm64) intermittently hangs
when a team is opened from inside such a region: main thread and workers all park on one
libgomp mutex that nobody holds. Reduced to twenty lines with no library code --
!$omp parallel num_threads(1) / !$omp single / !$omp parallel do num_threads(3) -- it
hangs 7 runs in 8. Bisected, every clause is load-bearing: master instead of single never
hangs, an enclosing team of 2 never hangs, and no environment setting fixes it
(GOMP_SPINCOUNT=0 only moves 7/8 to 2/8). The library's own code is standard-conforming;
this predicate is what stops it building the shape. See feature_risks.md Risk-104.
This is what clamps an EXPLICIT threads=, which parquet_auto_thread_count's rule
deliberately does not touch. The two are different questions and the narrowness is the point:
an enclosing team of two or more never reproduced the hang in any configuration tried, so a
genuinely parallel caller's explicit request is still honoured in full.
logical function parquet_nested_team_unsafe() result(unsafe) #ifdef _OPENMP use omp_lib, only: omp_get_level, omp_get_active_level #endif unsafe = .false. #ifdef _OPENMP unsafe = omp_get_level() > 0 .and. omp_get_active_level() == 0 #endif end function parquet_nested_team_unsafe