http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691
Bug ID: 58691 Summary: OpenMP 4: Surprising results with OMP_PLACES= Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org I played around with OMP_PLACES and noticed the following oddness: First, create some OpenMP program: $ echo "end" > test.f90; gfortran -fopenmp test.f90 Using "threads", "cores" or "sockets", one gets a places result: $ OMP_PLACES='threads' OMP_DISPLAY_ENV=verbose ./a.out 2>&1 |grep OMP_PLACES OMP_PLACES = '{0},{1},{2},{3}' However, if one specifies a numerical value, one doesn't: $ OMP_PLACES='{0:2}' OMP_DISPLAY_ENV=verbose ./a.out 2>&1 |grep OMP_PLACES OMP_PLACES = '' The reason - as it turns out - is that one has in libgomp/env.c the following code: parse_places_var (const char *name) { ... if (strncasecmp (env, "threads", 7) == 0) { env += 7; level = 1; } ... if (level) { ... return gomp_affinity_init_level (level, count, false); } ... if (gomp_global_icv.bind_var == omp_proc_bind_false) return false; gomp_places_list_len = 0; gomp_places_list = gomp_affinity_alloc (count, false); Namely: If OMP_PROC_BIND is FALSE, which is the default, the affinity does not get set. * * * I think in terms of the OpenMP spec, everything is implementation defined. Nonetheless, the following should match common expectations: * Both ways of setting OMP_PLACES should act identically. * If the user has set OMP_PLACES, the default of OMP_PROC_BIND should change to TRUE. * If the user has explicitly set OMP_PROC_BIND=FALSE, OMP_PLACES should be ignored. * Probably, a few words in libgomp.text's OMP_PROC_BIND or OMP_PLACES to the interaction of the two wouldn't harm either.