* [Bug fortran/101535] ICE in lookup_decl, at omp-low.c:412
2021-07-20 16:59 [Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412 gscfq@t-online.de
@ 2021-07-20 17:05 ` jakub at gcc dot gnu.org
2021-07-21 7:50 ` [Bug middle-end/101535] " cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-20 17:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
void
foo (void)
{
int a = 1, i;
#pragma omp target data map(to:a)
#pragma omp for lastprivate(i)
for (i = 1; i < 2; i++)
;
}
ICEs too. With the target data directive commented out it is diagnosed:
lastprivate variable ‘i’ is private in outer context
so I think we should make sure we don't consider the target data affecting it
in any way.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
2021-07-20 16:59 [Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412 gscfq@t-online.de
2021-07-20 17:05 ` [Bug fortran/101535] " jakub at gcc dot gnu.org
@ 2021-07-21 7:50 ` cvs-commit at gcc dot gnu.org
2021-07-21 8:22 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-21 7:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:b136b7a78774107943fe94051c42b5a968a3ad3f
commit r12-2433-gb136b7a78774107943fe94051c42b5a968a3ad3f
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Jul 21 09:45:02 2021 +0200
openmp: Fix up omp_check_private [PR101535]
The target data construct shouldn't affect omp_check_private, unless
the decl there is privatized (use_device_* clauses). The routine
had some code for that, but it just did continue; in a loop that looped
only if the region type is one of selected 4 kinds, so effectively resulted
in return false; instead of looping again. And not diagnosing lastprivate
(or reduction etc.) on a variable that is private to containing parallel
results in ICEs later on, as there is no original list item to which store
the last result.
The target construct is unclear as it has an implicit parallel region
and it is not obvious if the data privatization clauses on the construct
shall be treated as data privatization on the implicit parallel or just
on the target. For now treat those as privatization on the implicit
parallel, but treat map clauses as shared on the implicit parallel.
2021-07-21 Jakub Jelinek <jakub@redhat.com>
PR middle-end/101535
* gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA
contexts in which decl isn't privatized and for ORT_TARGET return
false if decl is mapped.
* c-c++-common/gomp/pr101535-1.c: New test.
* c-c++-common/gomp/pr101535-2.c: New test.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
2021-07-20 16:59 [Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412 gscfq@t-online.de
2021-07-20 17:05 ` [Bug fortran/101535] " jakub at gcc dot gnu.org
2021-07-21 7:50 ` [Bug middle-end/101535] " cvs-commit at gcc dot gnu.org
@ 2021-07-21 8:22 ` cvs-commit at gcc dot gnu.org
2021-07-21 8:28 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-21 8:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:076930b9690ac3564638636f6b13bbb6bc608aea
commit r11-8792-g076930b9690ac3564638636f6b13bbb6bc608aea
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Jul 21 09:45:02 2021 +0200
openmp: Fix up omp_check_private [PR101535]
The target data construct shouldn't affect omp_check_private, unless
the decl there is privatized (use_device_* clauses). The routine
had some code for that, but it just did continue; in a loop that looped
only if the region type is one of selected 4 kinds, so effectively resulted
in return false; instead of looping again. And not diagnosing lastprivate
(or reduction etc.) on a variable that is private to containing parallel
results in ICEs later on, as there is no original list item to which store
the last result.
The target construct is unclear as it has an implicit parallel region
and it is not obvious if the data privatization clauses on the construct
shall be treated as data privatization on the implicit parallel or just
on the target. For now treat those as privatization on the implicit
parallel, but treat map clauses as shared on the implicit parallel.
2021-07-21 Jakub Jelinek <jakub@redhat.com>
PR middle-end/101535
* gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA
contexts in which decl isn't privatized and for ORT_TARGET return
false if decl is mapped.
* c-c++-common/gomp/pr101535-1.c: New test.
* c-c++-common/gomp/pr101535-2.c: New test.
(cherry picked from commit b136b7a78774107943fe94051c42b5a968a3ad3f)
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
2021-07-20 16:59 [Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412 gscfq@t-online.de
` (2 preceding siblings ...)
2021-07-21 8:22 ` cvs-commit at gcc dot gnu.org
@ 2021-07-21 8:28 ` jakub at gcc dot gnu.org
2022-05-10 8:20 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-21 8:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2021-07-21
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.2 and trunk so far.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
2021-07-20 16:59 [Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412 gscfq@t-online.de
` (3 preceding siblings ...)
2021-07-21 8:28 ` jakub at gcc dot gnu.org
@ 2022-05-10 8:20 ` cvs-commit at gcc dot gnu.org
2022-05-11 6:21 ` cvs-commit at gcc dot gnu.org
2022-05-11 6:36 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-10 8:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535
--- Comment #5 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:69f1936c6700403fb94920f44346a5e2a66e2f86
commit r10-10637-g69f1936c6700403fb94920f44346a5e2a66e2f86
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Jul 21 09:45:02 2021 +0200
openmp: Fix up omp_check_private [PR101535]
The target data construct shouldn't affect omp_check_private, unless
the decl there is privatized (use_device_* clauses). The routine
had some code for that, but it just did continue; in a loop that looped
only if the region type is one of selected 4 kinds, so effectively resulted
in return false; instead of looping again. And not diagnosing lastprivate
(or reduction etc.) on a variable that is private to containing parallel
results in ICEs later on, as there is no original list item to which store
the last result.
The target construct is unclear as it has an implicit parallel region
and it is not obvious if the data privatization clauses on the construct
shall be treated as data privatization on the implicit parallel or just
on the target. For now treat those as privatization on the implicit
parallel, but treat map clauses as shared on the implicit parallel.
2021-07-21 Jakub Jelinek <jakub@redhat.com>
PR middle-end/101535
* gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA
contexts in which decl isn't privatized and for ORT_TARGET return
false if decl is mapped.
* c-c++-common/gomp/pr101535-1.c: New test.
* c-c++-common/gomp/pr101535-2.c: New test.
(cherry picked from commit b136b7a78774107943fe94051c42b5a968a3ad3f)
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
2021-07-20 16:59 [Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412 gscfq@t-online.de
` (4 preceding siblings ...)
2022-05-10 8:20 ` cvs-commit at gcc dot gnu.org
@ 2022-05-11 6:21 ` cvs-commit at gcc dot gnu.org
2022-05-11 6:36 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-11 6:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:3155bb8e475fa4752cc635ed5481b5339283de55
commit r9-10094-g3155bb8e475fa4752cc635ed5481b5339283de55
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Jul 21 09:45:02 2021 +0200
openmp: Fix up omp_check_private [PR101535]
The target data construct shouldn't affect omp_check_private, unless
the decl there is privatized (use_device_* clauses). The routine
had some code for that, but it just did continue; in a loop that looped
only if the region type is one of selected 4 kinds, so effectively resulted
in return false; instead of looping again. And not diagnosing lastprivate
(or reduction etc.) on a variable that is private to containing parallel
results in ICEs later on, as there is no original list item to which store
the last result.
The target construct is unclear as it has an implicit parallel region
and it is not obvious if the data privatization clauses on the construct
shall be treated as data privatization on the implicit parallel or just
on the target. For now treat those as privatization on the implicit
parallel, but treat map clauses as shared on the implicit parallel.
2021-07-21 Jakub Jelinek <jakub@redhat.com>
PR middle-end/101535
* gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA
contexts in which decl isn't privatized and for ORT_TARGET return
false if decl is mapped.
* c-c++-common/gomp/pr101535-1.c: New test.
* c-c++-common/gomp/pr101535-2.c: New test.
(cherry picked from commit b136b7a78774107943fe94051c42b5a968a3ad3f)
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
2021-07-20 16:59 [Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412 gscfq@t-online.de
` (5 preceding siblings ...)
2022-05-11 6:21 ` cvs-commit at gcc dot gnu.org
@ 2022-05-11 6:36 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-11 6:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 8+ messages in thread