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]

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


On Thu, Aug 20, 2009 at 10:51 AM, Alexandre Oliva<aoliva@redhat.com> wrote:
> 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.

The correct fix is to rewrite expansion to not re-build generic.  We
are workign on that for 4.5.

Richard.


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