public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/100471] #pragma omp taskloop with custom reduction Date: Tue, 10 May 2022 08:17:42 +0000 [thread overview] Message-ID: <bug-100471-4-WbyyhAW9h5@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-100471-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471 --- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-10 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:49bfa539e240cd769179751f18c472f9a4ea2248 commit r10-10608-g49bfa539e240cd769179751f18c472f9a4ea2248 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue May 11 09:07:47 2021 +0200 openmp: Fix up taskloop reduction ICE if taskloop has no iterations [PR100471] When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early return, doesn't create any tasks and more importantly, doesn't create a taskgroup and doesn't register task reductions. But, the code emitted in the callers assumes task reductions have been registered and performs the reduction handling and task reduction unregistration. The pointer to the task reduction private variables is reused, on input it is the alignment and only on output it is the pointer, so in the case taskloop with no iterations the caller attempts to dereference the alignment value as if it was a pointer and crashes. We could in the early returns register the task reductions only to have them looped over and unregistered in the caller, but I think it is better to tell the caller there is nothing to task reduce and bypass all that. 2021-05-11 Jakub Jelinek <jakub@redhat.com> PR middle-end/100471 * omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data is 0, bypass the reduction loop including GOMP_taskgroup_reduction_unregister call. * taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task reduction pointer. * testsuite/libgomp.c/task-reduction-4.c: New test. (cherry picked from commit 98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a)
next prev parent reply other threads:[~2022-05-10 8:17 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-07 11:17 [Bug middle-end/100471] New: #pragma omp taskloop with tom.vanderaa at gmail dot com 2021-05-07 11:33 ` [Bug middle-end/100471] #pragma omp taskloop with custom reduction jakub at gcc dot gnu.org 2021-05-07 13:03 ` tom.vanderaa at gmail dot com 2021-05-10 10:28 ` jakub at gcc dot gnu.org 2021-05-10 11:54 ` jakub at gcc dot gnu.org 2021-05-10 14:46 ` tom.vanderaa at gmail dot com 2021-05-11 7:13 ` cvs-commit at gcc dot gnu.org 2021-05-12 13:24 ` cvs-commit at gcc dot gnu.org 2021-05-12 13:29 ` jakub at gcc dot gnu.org 2022-05-10 8:17 ` cvs-commit at gcc dot gnu.org [this message] 2022-05-11 6:19 ` cvs-commit at gcc dot gnu.org 2022-05-11 6:33 ` jakub at gcc dot gnu.org
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=bug-100471-4-WbyyhAW9h5@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).