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 r12-5337] lim: Reset flow sensitive info even for pointers [PR103192]
Date: Wed, 17 Nov 2021 13:19:18 +0000 (GMT)	[thread overview]
Message-ID: <20211117131918.9AD403858D28@sourceware.org> (raw)

https://gcc.gnu.org/g:077425c890927eefacb765ab5236060de9859e82

commit r12-5337-g077425c890927eefacb765ab5236060de9859e82
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.

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 4b187c2cdaf..8a81acae115 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -1183,14 +1183,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);
     }
@@ -1253,14 +1249,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:[~2021-11-17 13:19 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=20211117131918.9AD403858D28@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).