This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR 40464] Intra-SRA workaround so that PR 40464 is not hit
- From: Martin Jambor <mjambor at suse dot cz>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Guenther <rguenther at suse dot de>
- Date: Fri, 7 Aug 2009 02:19:39 +0200
- Subject: Re: [PATCH, PR 40464] Intra-SRA workaround so that PR 40464 is not hit
- References: <20090806175406.GD24310@virgil.suse.cz> <4A7B4992.9060204@redhat.com>
On Thu, Aug 06, 2009 at 02:22:26PM -0700, Richard Henderson wrote:
> On 08/06/2009 10:54 AM, Martin Jambor wrote:
> >tree-complex.c does not do this by itself but through a call to
> >force_gimple_opernad_gsi on "REALPART_EXPR<b._M_value>" which leads
> >to invocation of gimplify_var_or_parm_decl on decl "b", which, being
> >DECL_HAS_VALUE_EXPR_P, is translated by the means of DECL_VALUE_EXPR
> >into the variable that is already dead. More details are in the bug.
>
> From the comment in front of DECL_VALUE_EXPR:
> ... once this field has been set, the decl itself may not
> legitimately appear in the function.
>
> So the bug is, in fact, that it appears as an argument to the
> REALPART_EXPR at all. Where does the thing come from (or fail
> to go away from) in the first place?
>
The second instruction of the first BB in function multiply of
g++.dg/torture/pr34099.C is "b.3 = b;" since the first gimple dump.
The b on the RHS has a DECL_VALUE_EXPR. That is where it comes from.
Thanks, I am curious where the bug will eventually be.
Martin