This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[vta, vta4.4, trunk?, 4.4?] avoid modifying locus of expr in place


When a gimple assign stmt with a location has a single_rhs that is an
expr, gimple_assign_rhs_to_tree() will overwrite the location of the
tree with that of the stmt.

I'm not even sure this overriding is desirable, but it surely causes
some unexpected results in VTA.  This function is called to propagate
the RHS of an SSA DEF into its USEs in debug stmts, when the SSA DEF is
about to be released.

However, since tree-ssa-ccp.c may have propagated the same (shared)
single_rhs tree to other USEs (it doesn't unshare ADDR_EXPRs), location
information may end up in these ADDR_EXPRs.

This shouldn't generally be a problem, but whether or not we propagate
this location information should not depend on whether there are debug
stmts referencing an SSA DEF that gets released with an ADDR_EXPR as its
single_rhs.

The location information added by VTA's release_ssa_name (that calls
propagate_defs_into_debug_stmts that indirectly calls
gimple_assign_rhs_to_tree) ends up causing different line numbers to be
emitted for insns in constructor calls in ios_init.cc, on the -m32 build
of libstdc++ on x86_64-linux-gnu, and this triggers an -fcompare-debug
failure.

This patch arranges for the expr in a single rhs to not be modified by
gimple_assign_rhs_to_tree().  (For a non-single rhs, we always build a
new tree, so we're not affected by the modification of t's location
right below the context in the patch.)

Does this sound like the right approach to fix the problem?  Is this
desirable for trunk or 4.4 branches?  It doesn't fix any codegen
problems in there AFAIK, and there's only one non-expand use of this
function, which might get extraneous line number information elsewhere
because of this behavior.

I'm still testing this patch, but unless I get other suggestions, I'll
install it in the VTA and VTA4.4 branches once I'm done with testing.

for  gcc/ChangeLog.vta
from  Alexandre Oliva  <aoliva@redhat.com>

	* cfgexpand.c (gimple_assign_rhs_to_tree): Do not overwrite
	location of single rhs in place.

Index: gcc/cfgexpand.c
===================================================================
--- gcc/cfgexpand.c.orig	2009-08-18 18:57:09.000000000 -0300
+++ gcc/cfgexpand.c	2009-08-20 05:24:19.000000000 -0300
@@ -70,7 +70,13 @@ gimple_assign_rhs_to_tree (gimple stmt)
 		TREE_TYPE (gimple_assign_lhs (stmt)),
 		gimple_assign_rhs1 (stmt));
   else if (grhs_class == GIMPLE_SINGLE_RHS)
-    t = gimple_assign_rhs1 (stmt);
+    {
+      t = gimple_assign_rhs1 (stmt);
+      /* Avoid modifying this tree in place below.  */
+      if (gimple_has_location (stmt) && CAN_HAVE_LOCATION_P (t)
+	  && gimple_location (stmt) != EXPR_LOCATION (t))
+	t = copy_node (t);
+    }
   else
     gcc_unreachable ();
 
-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]