public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r10-10654] lim: Reset flow sensitive info even for pointers [PR103192]
Date: Tue, 10 May 2022 08:21:41 +0000 (GMT)	[thread overview]
Message-ID: <20220510082141.8798838346AF@sourceware.org> (raw)

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

commit r10-10654-gbce66daa009ae64d1b0fa5ed0188b184767d7081
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Nov 17 14:18:42 2021 +0100

    lim: Reset flow sensitive info even for pointers [PR103192]
    
    Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
    if moving them from conditional contexts inside of a loop into unconditional
    before the loop, but as the miscompilation of gimplify.c shows, we need to
    treat pointers the same, even for them we need to reset whether the pointer
    can/can't be null or the recorded pointer alignment.
    
    This fixes
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal compiler error)
    -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for excess errors)
    -UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c compilation failed to produce executable
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (internal compiler error)
    -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test for excess errors)
    -UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c compilation failed to produce executable
    -FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
    -FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
    -UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to produce executable
    on both x86_64 and i686.
    
    2021-11-17  Jakub Jelinek  <jakub@redhat.com>
    
            PR tree-optimization/103192
            * tree-ssa-loop-im.c (move_computations_worker): Use
            reset_flow_sensitive_info instead of manually clearing
            SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones
            with integral types.
    
    (cherry picked from commit 077425c890927eefacb765ab5236060de9859e82)

Diff:
---
 gcc/tree-ssa-loop-im.c | 18 +++++-------------
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index abd5f702b91..b2cce4fc6ed 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -1170,14 +1170,10 @@ move_computations_worker (basic_block bb)
 					  COND_EXPR, t, arg0, arg1);
 	  todo |= TODO_cleanup_cfg;
 	}
-      if (INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (new_stmt)))
-	  && (!ALWAYS_EXECUTED_IN (bb)
-	      || (ALWAYS_EXECUTED_IN (bb) != level
-		  && !flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level))))
-	{
-	  tree lhs = gimple_assign_lhs (new_stmt);
-	  SSA_NAME_RANGE_INFO (lhs) = NULL;
-	}
+      if (!ALWAYS_EXECUTED_IN (bb)
+	  || (ALWAYS_EXECUTED_IN (bb) != level
+	      && !flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level)))
+	reset_flow_sensitive_info (gimple_assign_lhs (new_stmt));
       gsi_insert_on_edge (loop_preheader_edge (level), new_stmt);
       remove_phi_node (&bsi, false);
     }
@@ -1240,14 +1236,10 @@ move_computations_worker (basic_block bb)
       gsi_remove (&bsi, false);
       if (gimple_has_lhs (stmt)
 	  && TREE_CODE (gimple_get_lhs (stmt)) == SSA_NAME
-	  && INTEGRAL_TYPE_P (TREE_TYPE (gimple_get_lhs (stmt)))
 	  && (!ALWAYS_EXECUTED_IN (bb)
 	      || !(ALWAYS_EXECUTED_IN (bb) == level
 		   || flow_loop_nested_p (ALWAYS_EXECUTED_IN (bb), level))))
-	{
-	  tree lhs = gimple_get_lhs (stmt);
-	  SSA_NAME_RANGE_INFO (lhs) = NULL;
-	}
+	reset_flow_sensitive_info (gimple_get_lhs (stmt));
       /* In case this is a stmt that is not unconditionally executed
          when the target loop header is executed and the stmt may
 	 invoke undefined integer or pointer overflow rewrite it to


                 reply	other threads:[~2022-05-10  8:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220510082141.8798838346AF@sourceware.org \
    --to=jakub@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).