public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-4438] openmp: Fix up handling of OMP_PLACES=threads(1) Date: Fri, 15 Oct 2021 14:28:22 +0000 (GMT) [thread overview] Message-ID: <20211015142822.944153858C60@sourceware.org> (raw) https://gcc.gnu.org/g:4764049dd620affcd3e2658dc7f03a6616370a29 commit r12-4438-g4764049dd620affcd3e2658dc7f03a6616370a29 Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Oct 15 16:25:25 2021 +0200 openmp: Fix up handling of OMP_PLACES=threads(1) When writing the places-*.c tests, I've noticed that we mishandle threads abstract name with specified num-places if num-places isn't a multiple of number of hw threads in a core. It then happily ignores the maximum count and overwrites for the remaining hw threads in a core further places that haven't been allocated. 2021-10-15 Jakub Jelinek <jakub@redhat.com> * config/linux/affinity.c (gomp_affinity_init_level_1): For level 1 after creating count places clean up and return immediately. * testsuite/libgomp.c/places-6.c: New test. * testsuite/libgomp.c/places-7.c: New test. * testsuite/libgomp.c/places-8.c: New test. * testsuite/libgomp.c/places-9.c: New test. * testsuite/libgomp.c/places-10.c: New test. Diff: --- libgomp/config/linux/affinity.c | 9 +++++++-- libgomp/testsuite/libgomp.c/places-10.c | 10 ++++++++++ libgomp/testsuite/libgomp.c/places-6.c | 10 ++++++++++ libgomp/testsuite/libgomp.c/places-7.c | 10 ++++++++++ libgomp/testsuite/libgomp.c/places-8.c | 10 ++++++++++ libgomp/testsuite/libgomp.c/places-9.c | 10 ++++++++++ 6 files changed, 57 insertions(+), 2 deletions(-) diff --git a/libgomp/config/linux/affinity.c b/libgomp/config/linux/affinity.c index 82981b65472..69e72a8d141 100644 --- a/libgomp/config/linux/affinity.c +++ b/libgomp/config/linux/affinity.c @@ -338,8 +338,13 @@ gomp_affinity_init_level_1 (int level, int this_level, unsigned long count, if (gomp_affinity_add_cpus (pl, first, 1, 0, true)) { CPU_CLR_S (first, gomp_cpuset_size, copy); - if (level == 1) - gomp_places_list_len++; + if (level == 1 + && ++gomp_places_list_len >= count) + { + fclose (f); + free (line); + return; + } } } if (*p == ',') diff --git a/libgomp/testsuite/libgomp.c/places-10.c b/libgomp/testsuite/libgomp.c/places-10.c new file mode 100644 index 00000000000..7746b15cb44 --- /dev/null +++ b/libgomp/testsuite/libgomp.c/places-10.c @@ -0,0 +1,10 @@ +/* { dg-set-target-env-var OMP_PLACES "numa_domains(1)" } */ + +#include <omp.h> + +int +main () +{ + omp_display_env (0); + return 0; +} diff --git a/libgomp/testsuite/libgomp.c/places-6.c b/libgomp/testsuite/libgomp.c/places-6.c new file mode 100644 index 00000000000..bf552fbe2d4 --- /dev/null +++ b/libgomp/testsuite/libgomp.c/places-6.c @@ -0,0 +1,10 @@ +/* { dg-set-target-env-var OMP_PLACES "threads(1)" } */ + +#include <omp.h> + +int +main () +{ + omp_display_env (0); + return 0; +} diff --git a/libgomp/testsuite/libgomp.c/places-7.c b/libgomp/testsuite/libgomp.c/places-7.c new file mode 100644 index 00000000000..07f3d97e7b2 --- /dev/null +++ b/libgomp/testsuite/libgomp.c/places-7.c @@ -0,0 +1,10 @@ +/* { dg-set-target-env-var OMP_PLACES "cores(1)" } */ + +#include <omp.h> + +int +main () +{ + omp_display_env (0); + return 0; +} diff --git a/libgomp/testsuite/libgomp.c/places-8.c b/libgomp/testsuite/libgomp.c/places-8.c new file mode 100644 index 00000000000..ca7d55bc7a8 --- /dev/null +++ b/libgomp/testsuite/libgomp.c/places-8.c @@ -0,0 +1,10 @@ +/* { dg-set-target-env-var OMP_PLACES "sockets(1)" } */ + +#include <omp.h> + +int +main () +{ + omp_display_env (0); + return 0; +} diff --git a/libgomp/testsuite/libgomp.c/places-9.c b/libgomp/testsuite/libgomp.c/places-9.c new file mode 100644 index 00000000000..627cdcea538 --- /dev/null +++ b/libgomp/testsuite/libgomp.c/places-9.c @@ -0,0 +1,10 @@ +/* { dg-set-target-env-var OMP_PLACES "ll_caches(1)" } */ + +#include <omp.h> + +int +main () +{ + omp_display_env (0); + return 0; +}
reply other threads:[~2021-10-15 14:28 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211015142822.944153858C60@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).