This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[vta, vta4.4, trunk?, 4.4?] avoid modifying locus of expr in place
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Aug 2009 05:51:54 -0300
- Subject: [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