https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
--- Comment #4 from Stijn De Weirdt <stijn.deweirdt at ugent dot be> --- hi jakub, thanks for the explanation. so if i understand this, the main thread/process of any binary linked with libgomp becomes an OpenMP thread, because of the libgomp constructor doing something. and thus the OMP_PROC_BIND works as intended. and what happens with other threads created in the code in such a case? these are not openmp threads? or those are openmp threads, but related to the "nesting"/"active levels"? and can we "delay" the OMP_PROC_BIND safely (eg start the binary without OMP_PROC_BIND, and "enable" it in the main; i am more thinking in python code here: so after the import, we set the enviroment with OMP_PROC_BIND=true). will this cause pinning for openmp threads started afterwards? anyway, apologies again for my confusion and lack of detailed understanding. i still find it a bit unexpected ;) stijn
