[Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412

[Bug fortran/101535] New: ICE in lookup_decl, at omp-low.c:412

[gscfq@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535

            Bug ID: 101535
           Summary: ICE in lookup_decl, at omp-low.c:412
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   !$omp target data map(to:a)
   !$omp do lastprivate(i)
   do i = 1, 2
   end do
   !$omp end target data
end


$ gfortran-12-20210718 -c z1.f90 -fopenmp
during GIMPLE pass: omplower
z1.f90:3:26:

    3 |    !$omp do lastprivate(i)
      |                          ^
internal compiler error: Segmentation fault
0xc9a8df crash_signal
        ../../gcc/toplev.c:328
0xb71c1c lookup_decl
        ../../gcc/omp-low.c:412
0xb71c1c build_outer_var_ref
        ../../gcc/omp-low.c:729
0xb8049b lower_rec_input_clauses
        ../../gcc/omp-low.c:5722
0xb8a5da lower_omp_for
        ../../gcc/omp-low.c:11423
0xb78071 lower_omp_1
        ../../gcc/omp-low.c:13853
0xb78071 lower_omp
        ../../gcc/omp-low.c:14040
0xb7897d lower_omp_1
        ../../gcc/omp-low.c:13837
0xb7897d lower_omp
        ../../gcc/omp-low.c:14040
0xb78108 lower_omp_1
        ../../gcc/omp-low.c:13824
0xb78108 lower_omp
        ../../gcc/omp-low.c:14040
0xb7c713 lower_omp_target
        ../../gcc/omp-low.c:12600
0xb7c713 lower_omp_1
        ../../gcc/omp-low.c:13902
0xb7c713 lower_omp
        ../../gcc/omp-low.c:14040
0xb78108 lower_omp_1
        ../../gcc/omp-low.c:13824
0xb78108 lower_omp
        ../../gcc/omp-low.c:14040
0xb7897d lower_omp_1
        ../../gcc/omp-low.c:13837
0xb7897d lower_omp
        ../../gcc/omp-low.c:14040
0xb7f911 execute_lower_omp
        ../../gcc/omp-low.c:14079
0xb7f911 execute
        ../../gcc/omp-low.c:14127

[Bug fortran/101535] ICE in lookup_decl, at omp-low.c:412

[jakub at gcc dot gnu.org]

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.

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[cvs-commit at gcc dot gnu.org]

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.

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[cvs-commit at gcc dot gnu.org]

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)

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[jakub at gcc dot gnu.org]

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.

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[cvs-commit at gcc dot gnu.org]

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)

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[cvs-commit at gcc dot gnu.org]

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)

[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412

[jakub at gcc dot gnu.org]

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.