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.
if (gimple_debug_bind_p (stmt))
{
tree val = gimple_debug_bind_get_value (stmt);
- if (val
- && REFERENCE_CLASS_P (val))
+ if (val && REFERENCE_CLASS_P (val))
{
tree tem = maybe_fold_reference (val);
if (tem)
changed = true;
}
}
- 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;
- }
- }
}
break;
--- /dev/null
+! PR fortran/103691
+! { dg-do compile }
+! { dg-options "-O2 -g" }
+
+program pr103691
+ real, parameter :: a(0) = 2.0
+ real, allocatable :: b(:)
+ allocate (b, mold=a)
+end