[Bug c/98088] New: [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[Bug c/98088] New: [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[gscfq@t-online.de]

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

            Bug ID: 98088
           Summary: [9/10/11 Regression] ICE in expand_oacc_collapse_init,
                    at omp-expand.c:1533
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started with r7 :


$ cat z1.c
void f ()
{
  #pragma acc parallel loop tile(2, 3)
  for (int i = 0; i > 8; i++)
    for (int j = 0; j > 8; j++);
}


$ cat z2.c
void f ()
{
  #pragma acc parallel loop tile(2, 3)
  for (int i = 0; i > 8; i++)
    for (long j = 0; j > 8; j++);
}


$ gcc-6 -c z1.c -fopenmp -fopenacc
$
$ gcc-11-20201129 -c z1.c -fopenmp -fopenacc
during GIMPLE pass: ompexp
z1.c: In function 'f':
z1.c:3:11: internal compiler error: in expand_oacc_collapse_init, at
omp-expand.c:1533
    3 |   #pragma acc parallel loop tile(2, 3)
      |           ^~~
0x1479f31 expand_oacc_collapse_init
        ../../gcc/omp-expand.c:1533
0x1479f31 expand_oacc_for
        ../../gcc/omp-expand.c:7537
0x148f361 expand_omp_for
        ../../gcc/omp-expand.c:8011
0x148fd5a expand_omp
        ../../gcc/omp-expand.c:9901
0x149008e expand_omp
        ../../gcc/omp-expand.c:9887
0x1491bed execute_expand_omp
        ../../gcc/omp-expand.c:10133

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code, openmp
          Component|c                           |middle-end
   Target Milestone|---                         |9.4

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cltang at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-01-29
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r7-6598-g02889d23ee3b02854dff203dd87b9a25e30b61b4

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Doesn't ICE if the conditions match the iteration direction, the way it is
written it will never iterate, and if it would iterate (say int i = 0; i > -3;
i++) it would be invalid OpenACC.  Doesn't ICE for int i = 0; i < -3; i++) that
never iterates and has the comparison in the corresponding direction to the
step.

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
void
foo (int a[32][32])
{
  #pragma acc parallel loop collapse(2)
  for (int i = 16; i > 8; i--)
    for (int j = 16; j > 8; j--)
      a[i][j] = i + j;
}

ICEs too.
The
1544          gcc_assert (loop->cond_code == fd->loop.cond_code);
assertion is just wrong, at least generic code for collapsed loops makes the
fd->loop.cond_code always LT_EXPR, it iterates from 0 to number of logical
iterations of the loop nest, while the individual loops in the loop nest can go
in various directions.
This exact testcase started to ICE with the introduction of
expand_oacc_collapse_init in r6-4364-ge4834818d22f5c663b24940fd5b04da266e11fe8

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hafiz Abid Qadeer <abidh@gcc.gnu.org>:

https://gcc.gnu.org/g:ac200799acb5cd2fb9e1758f6bf5fff1978daaeb

commit r11-8123-gac200799acb5cd2fb9e1758f6bf5fff1978daaeb
Author: Hafiz Abid Qadeer <abidh@codesourcery.com>
Date:   Thu Apr 8 17:31:30 2021 +0100

    [OpenACC] Fix an ICE where a loop with GT condition is collapsed.

    We have seen an ICE both on trunk and devel/omp/gcc-10 branches which can
    be reprodued with this simple testcase.  It occurs if an OpenACC loop has
    a collapse clause and any of the loop being collapsed uses GT or GE
    condition.  This issue is specific to OpenACC.

    int main (void)
    {
      int ix, iy;
      int dim_x = 16, dim_y = 16;
      {
           for (iy = dim_y - 1; iy > 0; --iy)
           for (ix = dim_x - 1; ix > 0; --ix)
            ;
      }
    }

    The problem is caused by a failing assertion in expand_oacc_collapse_init.
    It checks that cond_code for fd->loop should be same as cond_code for all
    the loops that are being collapsed.  As the cond_code for fd->loop is
    LT_EXPR with collapse clause (set at the end of omp_extract_for_data),
    this assertion forces that all the loop in collapse clause should use
    < operator.

    There does not seem to be anything in the code which demands this
    condition as loop with > condition works ok otherwise.  I digged old
    mailing list a bit but could not find any discussion on this change.
    Looking at the code, expand_oacc_for checks that fd->loop->cond_code is
    either LT_EXPR or GT_EXPR.  I guess the original intention was to have
    similar checks on the loop which are being collapsed. But the way check
    was written does not acheive that.

    I have fixed it by modifying the check in the assertion to be same as
    check on fd->loop->cond_code.

    I tested goacc and libgomp (with nvptx offloading) and did not see any
    regression.  I have added new tests to check collapse with GT/GE condition.

            PR middle-end/98088
            gcc/
            * omp-expand.c (expand_oacc_collapse_init): Update condition in
            a gcc_assert.

            gcc/testsuite/
            * c-c++-common/goacc/collapse-2.c: New.

            libgomp/
            * testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Add check
            for loop with GT/GE condition.
            * testsuite/libgomp.oacc-c-c++-common/collapse-3.c: Likewise.

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[abidh at gcc dot gnu.org]

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

Hafiz Abid qadeer <abidh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from Hafiz Abid qadeer <abidh at gcc dot gnu.org> ---
Fixed in ac200799acb5cd2fb9e1758f6bf5fff1978daaeb.

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Hafiz Abid Qadeer
<abidh@gcc.gnu.org>:

https://gcc.gnu.org/g:e4dcb3383bff4c209a918127551cabc56b4171ae

commit r10-9711-ge4dcb3383bff4c209a918127551cabc56b4171ae
Author: Hafiz Abid Qadeer <abidh@codesourcery.com>
Date:   Thu Apr 8 17:31:30 2021 +0100

    [OpenACC] Fix an ICE where a loop with GT condition is collapsed.

    We have seen an ICE both on trunk and devel/omp/gcc-10 branches which can
    be reprodued with this simple testcase.  It occurs if an OpenACC loop has
    a collapse clause and any of the loop being collapsed uses GT or GE
    condition.  This issue is specific to OpenACC.

    int main (void)
    {
      int ix, iy;
      int dim_x = 16, dim_y = 16;
      {
           for (iy = dim_y - 1; iy > 0; --iy)
           for (ix = dim_x - 1; ix > 0; --ix)
            ;
      }
    }

    The problem is caused by a failing assertion in expand_oacc_collapse_init.
    It checks that cond_code for fd->loop should be same as cond_code for all
    the loops that are being collapsed.  As the cond_code for fd->loop is
    LT_EXPR with collapse clause (set at the end of omp_extract_for_data),
    this assertion forces that all the loop in collapse clause should use
    < operator.

    There does not seem to be anything in the code which demands this
    condition as loop with > condition works ok otherwise.  I digged old
    mailing list a bit but could not find any discussion on this change.
    Looking at the code, expand_oacc_for checks that fd->loop->cond_code is
    either LT_EXPR or GT_EXPR.  I guess the original intention was to have
    similar checks on the loop which are being collapsed. But the way check
    was written does not acheive that.

    I have fixed it by modifying the check in the assertion to be same as
    check on fd->loop->cond_code.

    I tested goacc and libgomp (with nvptx offloading) and did not see any
    regression.  I have added new tests to check collapse with GT/GE condition.

            PR middle-end/98088
            gcc/
            * omp-expand.c (expand_oacc_collapse_init): Update condition in
            a gcc_assert.

            gcc/testsuite/
            * c-c++-common/goacc/collapse-2.c: New.

            libgomp/
            * testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Add check
            for loop with GT/GE condition.
            * testsuite/libgomp.oacc-c-c++-common/collapse-3.c: Likewise.

    (cherry picked from commit ac200799acb5cd2fb9e1758f6bf5fff1978daaeb)