* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
@ 2021-12-14 10:05 ` marxin at gcc dot gnu.org
2021-12-14 15:43 ` amacleod at redhat dot com
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-12-14 10:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
2021-12-14 10:05 ` [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
@ 2021-12-14 15:43 ` amacleod at redhat dot com
2022-01-04 11:07 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: amacleod at redhat dot com @ 2021-12-14 15:43 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
2021-12-14 10:05 ` [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
2021-12-14 15:43 ` amacleod at redhat dot com
@ 2022-01-04 11:07 ` rguenth at gcc dot gnu.org
2022-01-04 11:32 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-01-04 11:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (2 preceding siblings ...)
2022-01-04 11:07 ` rguenth at gcc dot gnu.org
@ 2022-01-04 11:32 ` jakub at gcc dot gnu.org
2022-01-04 12:26 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-04 11:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (3 preceding siblings ...)
2022-01-04 11:32 ` jakub at gcc dot gnu.org
@ 2022-01-04 12:26 ` rguenth at gcc dot gnu.org
2022-01-04 12:28 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-01-04 12:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (4 preceding siblings ...)
2022-01-04 12:26 ` rguenth at gcc dot gnu.org
@ 2022-01-04 12:28 ` jakub at gcc dot gnu.org
2022-01-05 9:46 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-04 12:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (5 preceding siblings ...)
2022-01-04 12:28 ` jakub at gcc dot gnu.org
@ 2022-01-05 9:46 ` cvs-commit at gcc dot gnu.org
2022-01-05 9:49 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-01-05 9:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (6 preceding siblings ...)
2022-01-05 9:46 ` cvs-commit at gcc dot gnu.org
@ 2022-01-05 9:49 ` jakub at gcc dot gnu.org
2022-03-24 15:23 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-05 9:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (7 preceding siblings ...)
2022-01-05 9:49 ` jakub at gcc dot gnu.org
@ 2022-03-24 15:23 ` jakub at gcc dot gnu.org
2022-03-25 10:23 ` cvs-commit at gcc dot gnu.org
2022-03-25 10:23 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-03-24 15:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (8 preceding siblings ...)
2022-03-24 15:23 ` jakub at gcc dot gnu.org
@ 2022-03-25 10:23 ` cvs-commit at gcc dot gnu.org
2022-03-25 10:23 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-03-25 10:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14
2021-12-13 19:51 [Bug fortran/103691] New: [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 gscfq@t-online.de
` (9 preceding siblings ...)
2022-03-25 10:23 ` cvs-commit at gcc dot gnu.org
@ 2022-03-25 10:23 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-03-25 10:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread