* [PATCH] gimple-fold: Remove incorrect folding of debug stmts [PR103691]
@ 2022-01-05 9:25 Jakub Jelinek
2022-01-05 9:39 ` Richard Biener
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2022-01-05 9:25 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
Hi!
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.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
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.
--- gcc/gimple-fold.c.jj 2022-01-03 10:40:42.872140874 +0100
+++ gcc/gimple-fold.c 2022-01-04 13:29:17.571321684 +0100
@@ -6283,8 +6283,7 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
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)
@@ -6292,18 +6291,6 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
gimple_debug_bind_set_value (stmt, 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;
--- gcc/testsuite/gfortran.dg/pr103691.f90.jj 2022-01-04 13:31:23.564557726 +0100
+++ gcc/testsuite/gfortran.dg/pr103691.f90 2022-01-04 13:31:08.053774883 +0100
@@ -0,0 +1,9 @@
+! 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
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] gimple-fold: Remove incorrect folding of debug stmts [PR103691]
2022-01-05 9:25 [PATCH] gimple-fold: Remove incorrect folding of debug stmts [PR103691] Jakub Jelinek
@ 2022-01-05 9:39 ` Richard Biener
0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2022-01-05 9:39 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Wed, 5 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> 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.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
> 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.
>
> --- gcc/gimple-fold.c.jj 2022-01-03 10:40:42.872140874 +0100
> +++ gcc/gimple-fold.c 2022-01-04 13:29:17.571321684 +0100
> @@ -6283,8 +6283,7 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
> 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)
> @@ -6292,18 +6291,6 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
> gimple_debug_bind_set_value (stmt, 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;
> --- gcc/testsuite/gfortran.dg/pr103691.f90.jj 2022-01-04 13:31:23.564557726 +0100
> +++ gcc/testsuite/gfortran.dg/pr103691.f90 2022-01-04 13:31:08.053774883 +0100
> @@ -0,0 +1,9 @@
> +! 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
>
> Jakub
>
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-01-05 9:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-05 9:25 [PATCH] gimple-fold: Remove incorrect folding of debug stmts [PR103691] Jakub Jelinek
2022-01-05 9:39 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).