[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.4 --- Comment #9 from Jakub Jelinek --- Fixed on the trunk and all release branches.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fdaf101b1dd46d6673a318139e9620c068f45a12 commit r8-10015-gfdaf101b1dd46d6673a318139e9620c068f45a12 Author: Jakub Jelinek Date: Fri Feb 14 14:18:10 2020 +0100 openmp: Fix handling of non-addressable shared scalars in parallel nested inside of target [PR93515] As the following testcase shows, we need to consider even target to be a construct that forces not to use copy in/out for shared on parallel inside of the target. E.g. for parallel nested inside another parallel or host teams, we already avoid copy in/out and we need to treat target the same. 2020-02-06 Jakub Jelinek PR libgomp/93515 * omp-low.c (use_pointer_for_field): For nested constructs, also look for map clauses on target construct. (scan_omp_1_stmt) : Bump temporarily taskreg_nesting_level. * testsuite/libgomp.c-c++-common/pr93515.c: New test.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d3266b1311723841ec553277f1fb6bfddef8809d commit r9-8220-gd3266b1311723841ec553277f1fb6bfddef8809d Author: Jakub Jelinek Date: Thu Feb 6 09:15:13 2020 +0100 openmp: Notice reduction decl in outer contexts after adding it to shared [PR93515] If we call omp_add_variable, following omp_notice_variable will already find it on that construct and not go through outer constructs, the following patch fixes that. Note, this still doesn't follow OpenMP 5.0 semantics on target combined with other constructs with reduction/lastprivate/linear clauses, will handle that for GCC11. 2020-02-06 Jakub Jelinek PR libgomp/93515 * gimplify.c (gimplify_scan_omp_clauses) : If adding shared clause, call omp_notice_variable on outer context if any.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:05fa0de35ec63db2c3aacd30cc34a7389b3c4e5d commit r9-8221-g05fa0de35ec63db2c3aacd30cc34a7389b3c4e5d Author: Jakub Jelinek Date: Thu Feb 6 09:19:08 2020 +0100 openmp: Fix handling of non-addressable shared scalars in parallel nested inside of target [PR93515] As the following testcase shows, we need to consider even target to be a construct that forces not to use copy in/out for shared on parallel inside of the target. E.g. for parallel nested inside another parallel or host teams, we already avoid copy in/out and we need to treat target the same. 2020-02-06 Jakub Jelinek PR libgomp/93515 * omp-low.c (use_pointer_for_field): For nested constructs, also look for map clauses on target construct. (scan_omp_1_stmt) : Bump temporarily taskreg_nesting_level. * testsuite/libgomp.c-c++-common/pr93515.c: New test.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cb3f06480a17f98579704b9927632627a3814c5c commit r10-6471-gcb3f06480a17f98579704b9927632627a3814c5c Author: Jakub Jelinek Date: Thu Feb 6 09:19:08 2020 +0100 openmp: Fix handling of non-addressable shared scalars in parallel nested inside of target [PR93515] As the following testcase shows, we need to consider even target to be a construct that forces not to use copy in/out for shared on parallel inside of the target. E.g. for parallel nested inside another parallel or host teams, we already avoid copy in/out and we need to treat target the same. 2020-02-06 Jakub Jelinek PR libgomp/93515 * omp-low.c (use_pointer_for_field): For nested constructs, also look for map clauses on target construct. (scan_omp_1_stmt) : Bump temporarily taskreg_nesting_level. * testsuite/libgomp.c-c++-common/pr93515.c: New test.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cf785618ecc90e3f063b99572de48cb91aa5ab5d commit r10-6470-gcf785618ecc90e3f063b99572de48cb91aa5ab5d Author: Jakub Jelinek Date: Thu Feb 6 09:15:13 2020 +0100 openmp: Notice reduction decl in outer contexts after adding it to shared [PR93515] If we call omp_add_variable, following omp_notice_variable will already find it on that construct and not go through outer constructs, the following patch fixes that. Note, this still doesn't follow OpenMP 5.0 semantics on target combined with other constructs with reduction/lastprivate/linear clauses, will handle that for GCC11. 2020-02-06 Jakub Jelinek PR libgomp/93515 * gimplify.c (gimplify_scan_omp_clauses) : If adding shared clause, call omp_notice_variable on outer context if any.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #3 from Jakub Jelinek --- The patch unfortunately regressed: +FAIL: c-c++-common/gomp/loop-5.c (internal compiler error) +FAIL: c-c++-common/gomp/loop-5.c (test for excess errors) which looks like previously broken code on the testcase, but wI won't apply the patch until that issue gets fixed, so needs to wait for next week.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-31 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 47752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47752=edit gcc10-pr93515.patch Untested fix.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515
--- Comment #1 from Jakub Jelinek ---
Thanks for the report, confirmed. Simpler testcase:
#include
int
main ()
{
int i;
int a = 42;
#pragma omp target teams distribute parallel for defaultmap(tofrom: scalar)
for (i = 0; i < 64; ++i)
if (omp_get_team_num () == 0)
if (omp_get_thread_num () == 0)
a = 142;
if (a != 142)
__builtin_abort ();
return 0;
}
Quick workaround, tak address of the variable(s) somewhere, even with just
(void)
For the non-addressable scalar vars, gcc sometimes implements shared by taking
address of the variable and at other times by performing copy in/out (of course
not possible on task/taskloop). Copy in/out works fine if e.g. the parallel is
not nested in another parallel/teams or the shared variable is private in the
outer parallel/teams. If it is shared in both, copy in/out is not possible.
The reason why the above testcase is miscompiled is that the teams immediately
nested inside of target is (intentionally ignored), but we need to treat map
clauses similarly to the shared clauses. If you take out the target from the
above testcase, then it will work, the shared(a) on teams then forces shared(a)
on parallel to be passed through reference instead of copy in/out.
