[Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314

[Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314

[gscfq@t-online.de]

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

            Bug ID: 103691
           Summary: [12 Regression] ICE in
                    get_array_ctor_element_at_index, at fold-const.c:13314
           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: ---

Changed between 20211024 and 20211031 at -O2+ :
(gcc configured with --enable-checking=yes)


$ cat z1.f90
program p
   real, parameter :: a(0) = 2.0
   real, allocatable :: b(:)
   allocate (b, mold=a)
end


$ gfortran-12-20211024 -c z1.f90 -g -O2
$
$ gfortran-12-20211212 -c z1.f90 -g -O2
during GIMPLE pass: evrp
z1.f90:5:3:

    5 | end
      |   ^
internal compiler error: in get_array_ctor_element_at_index, at
fold-const.c:13314
0xb27c33 get_array_ctor_element_at_index(tree_node*,
generic_wide_int<fixed_wide_int_storage<128> >, unsigned int*)
        ../../gcc/fold-const.c:13314
0xb9ee55 fold_array_ctor_reference
        ../../gcc/gimple-fold.c:7862
0xb9ee55 fold_ctor_reference(tree_node*, tree_node*, poly_int<1u, unsigned
long> const&, poly_int<1u, unsigned long> const&, tree_node*, unsigned long*)
        ../../gcc/gimple-fold.c:8061
0xba1e18 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*))
        ../../gcc/gimple-fold.c:8186
0xba39f8 fold_const_aggregate_ref(tree_node*)
        ../../gcc/gimple-fold.c:8265
0xba39f8 maybe_fold_reference
        ../../gcc/gimple-fold.c:337
0xbaaa68 fold_stmt_1
        ../../gcc/gimple-fold.c:6301
0x1bbc20c gimple_ranger::fold_stmt(gimple_stmt_iterator*, tree_node*
(*)(tree_node*))
        ../../gcc/gimple-range.cc:434
0x11138c6 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
        ../../gcc/tree-ssa-propagate.c:870
0x1b82907 dom_walker::walk(basic_block_def*)
        ../../gcc/domwalk.c:309
0x1112945 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
        ../../gcc/tree-ssa-propagate.c:987
0x12217bd execute_ranger_vrp(function*, bool)
        ../../gcc/tree-vrp.c:4337
0x1bd658d execute_early_vrp
        ../../gcc/gimple-ssa-evrp.c:316

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
   Last reconfirmed|                            |2021-12-14
             Status|UNCONFIRMED                 |NEW
            Summary|[12 Regression] ICE in      |[12 Regression] ICE in
                   |get_array_ctor_element_at_i |get_array_ctor_element_at_i
                   |ndex, at fold-const.c:13314 |ndex, at fold-const.c:13314
                   |                            |since
                   |                            |r12-4694-gcb153222404e2e14
                 CC|                            |amacleod at redhat dot com,
                   |                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-4694-gcb153222404e2e14.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[amacleod at redhat dot com]

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

--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
Its triggering an assert in the gimple folder when trying to process:

# DEBUG D.4293 => &a[0]

The constructor shows:

  static real(kind=4) a[0] = {[0 ... -1]=2.0e+0};

is that a range of 0 to -1?  its triggering an assert in line 13314 of
fold_const:

gcc_checking_assert (wi::le_p (index, max_index, index_sgn));

it looks to be because max_index is less than index?

The referenced change causes this because it now calls gimple_fold on all stmts
instead of just ranger specific ones.  I presume we are suppose to call fold on
debug stmts too?

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yes, folding debug stmts is OK but we usually don't do that unless we
substitute into them (so that's maybe why the issue pops up now).  It might be
wise to avoid folding debug stmts as a workaround.

Clearly the RANGE_EXPR the Fortran FE builds here is wrong, but as far as I
understand the testcase is invalid?

   real, parameter :: a(0) = 2.0

that's an array with zero elements which you initialize.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
To me it looks like the PR52329 change wasn't correct.  In particular, it
should have been using true as the second argument and not false and therefore
should have been removed in the r12-21-g0bf8cd9d5e8ac changes rather than kept.
If I modify the testcase from a(0) to a(2), then I see
pr103691.f90.037t.fre1:  # DEBUG D.4293 => &a[0]
and
pr103691.f90.038t.evrp:  # DEBUG D.4293 => &2.0e+0
The &2.0e+0 is just a wrong-debug, debug info was supposed to contain address
of
a, not address of some constant that happens to be in the first element of the
array.
fold_stmt_1 earlier has:
    case GIMPLE_DEBUG:
      if (gimple_debug_bind_p (stmt))
        {
          tree *val = gimple_debug_bind_get_value_ptr (stmt);
          if (*val
              && (REFERENCE_CLASS_P (*val)
                  || TREE_CODE (*val) == ADDR_EXPR)
              && maybe_canonicalize_mem_ref_addr (val, true))
            changed = true;
        }
which I believe should perform whatever PR52329 was meant to deal with.
So I think
          else if (val
                   && TREE_CODE (val) == ADDR_EXPR)
            {
              tree ref = TREE_OPERAND (val, 0);
              tree tem = maybe_fold_reference (ref);
              if (tem)
                {
                  tem = build_fold_addr_expr_with_type (tem, TREE_TYPE (val));
                  gimple_debug_bind_set_value (stmt, tem);
                  changed = true;
                }
            }
should be just dropped.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> To me it looks like the PR52329 change wasn't correct.  In particular, it
> should have been using true as the second argument and not false and
> therefore should have been removed in the r12-21-g0bf8cd9d5e8ac changes
> rather than kept.
> If I modify the testcase from a(0) to a(2), then I see
> pr103691.f90.037t.fre1:  # DEBUG D.4293 => &a[0]
> and
> pr103691.f90.038t.evrp:  # DEBUG D.4293 => &2.0e+0
> The &2.0e+0 is just a wrong-debug, debug info was supposed to contain
> address of
> a, not address of some constant that happens to be in the first element of
> the array.
> fold_stmt_1 earlier has:
>     case GIMPLE_DEBUG:
>       if (gimple_debug_bind_p (stmt))
>         {
>           tree *val = gimple_debug_bind_get_value_ptr (stmt);
>           if (*val
>               && (REFERENCE_CLASS_P (*val)
>                   || TREE_CODE (*val) == ADDR_EXPR)
>               && maybe_canonicalize_mem_ref_addr (val, true))
>             changed = true;
>         }
> which I believe should perform whatever PR52329 was meant to deal with.
> So I think
>           else if (val
>                    && TREE_CODE (val) == ADDR_EXPR)
>             {
>               tree ref = TREE_OPERAND (val, 0);
>               tree tem = maybe_fold_reference (ref);
>               if (tem)
>                 {
>                   tem = build_fold_addr_expr_with_type (tem, TREE_TYPE
> (val));
>                   gimple_debug_bind_set_value (stmt, tem);
>                   changed = true;
>                 }
>             }
> should be just dropped.

Agreed.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, will test that change.
The FE should be probably also fixed to drop such initializers, there is no
point to have initializers for empty arrays.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:a4c2e62d60f47d47cdd94951e16b0de50495cdab

commit r12-6221-ga4c2e62d60f47d47cdd94951e16b0de50495cdab
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jan 5 10:45:26 2022 +0100

    gimple-fold: Remove incorrect folding of debug stmts [PR103691]

    For ADDR_EXPR gimple_debug_bind_get_value fold_stmt_1 uses
    maybe_canonicalize_mem_ref_addr earlier and I think that should
    resolve the concerns raised in PR52329.  But folding ADDR_EXPR
    operand using maybe_fold_reference and then taking address of that
    looks like an invalid transformation, it can transform
      # DEBUG D.4293 => &a[0]
    into
      # DEBUG D.4293 => &2.0e+0
    etc., all we want to allow are the lhs folding of the operand which
    maybe_fold_reference no longer does since r12-21-g0bf8cd9d5e8ac.

    2022-01-05  Jakub Jelinek  <jakub@redhat.com>

            PR fortran/103691
            * gimple-fold.c (fold_stmt_1): Don't call maybe_fold_reference
            for DEBUG stmts with ADDR_EXPR gimple_debug_bind_get_value,
            it can do unwanted rhs folding like &a[0] into &2.0 etc.

            * gfortran.dg/pr103691.f90: New test.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Regression now fixed though it would be nice to fix the FE too.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52681&action=edit
gcc12-pr103691.patch

Untested FE patch.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 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:45e955b0a936eafc9838cdc00dcc31b3799b321b

commit r12-7811-g45e955b0a936eafc9838cdc00dcc31b3799b321b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 25 11:22:15 2022 +0100

    fortran: Fix up initializers of param(0) PARAMETERs [PR103691]

    On the gfortran.dg/pr103691.f90 testcase the Fortran ICE emits
      static real(kind=4) a[0] = {[0 ... -1]=2.0e+0};
    That is an invalid RANGE_EXPR where the maximum is smaller than the
minimum.

    The following patch fixes that.  If TYPE_MAX_VALUE is smaller than
    TYPE_MIN_VALUE, the array is empty and so doesn't need any initializer,
    if the two are equal, we don't need to bother with a RANGE_EXPR and
    can just use that INTEGER_CST as the index and finally for the 2+ values
    in the range it uses a RANGE_EXPR as before.

    2022-03-25  Jakub Jelinek  <jakub@redhat.com>

            PR fortran/103691
            * trans-array.cc (gfc_conv_array_initializer): If TYPE_MAX_VALUE is
            smaller than TYPE_MIN_VALUE (i.e. empty array), ignore the
            initializer; if TYPE_MIN_VALUE is equal to TYPE_MAX_VALUE, use just
            the TYPE_MIN_VALUE as index instead of RANGE_EXPR.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.