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: Removing unnecessary ADDR_EXPRs


On 5/17/05, Jeffrey A Law <law@redhat.com> wrote:
> On Tue, 2005-05-17 at 22:29 +0200, Richard Guenther wrote:
> > On 5/17/05, Jeffrey A Law <law@redhat.com> wrote:
> > > On Tue, 2005-05-17 at 21:42 +0200, Richard Guenther wrote:
> > > > On 5/17/05, Jeffrey A Law <law@redhat.com> wrote:
> > > > > Can you dump the types of the outer INDIRECT_REF, the ADDR_EXPR and
> > > > > the first argument to the ADDR_EXPR?    The only way I can see folding
> > > > > failing is if there's a type bogosity somewhere.  I've instrumented that
> > > > > code locally, but haven't managed to make it trip yet.
> > > >
> > > > Sorry to followup again, but I suppose I merely trigger a latent bug elsewhere.
> > > > Actually, during rewrite_into_ssa we call parse_ssa_operands on
> > > > (&<retval>)->_M_stateD.32454 = __stD.41263 which finally calls
> > > > get_indirect_ref_operands with the above stmt and expr = *&<retval>
> > > > It isn't expecting an expr of this form, unfortunately.  So it looks something
> > > > before rewrite_into_ssa is producing non-gimple?  Actually changing all
> > > > fold_indirect_ref in tree-inline.c to fold_indirect_ref_rhs fixes the problem.
> > >
> > > Hmmm, we might be better off if you can send me whatever tweaks you've
> > > got in your tree.  There's most likely a type issue somewhere that's
> > > causing these problems, but it's going to be bloody hard to find via
> > > email :-)
> >
> > I have installed the patch contained in
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01689.html
> >
> > and the one referenced therein (which is the one that causes
> > the failure).
> OK.  I can see how that might be causing the problems you're seeing
> as that patch introduces cases where we do not fold away an
> INDIRECT_REF+ADDR_EXPR pair.
> 
> I'll go ahead and twiddle the the propagator to account for this
> possibility.  It just means we use a little more memory until we
> create a better "undo" capability

Actually, in tree-inline.c:copy_body_r we're asking build_fold_indirect_ref
to indirect through an ADDR_EXPR with mismatched types:

#1  0x0848cdb2 in build_fold_indirect_ref (t=0x410f0d20)
    at /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/fold-const.c:11516
11516	  tree sub = fold_indirect_ref_1 (type, t);
(gdb) call debug_generic_expr(t)
&<retval>
(gdb) call debug_tree(t)
 <addr_expr 0x410f0d20
    type <pointer_type 0x410efa8c
        type <record_type 0x40b50438 streampos asm_written
needs-constructing type_1 type_5 BLK
       .....
    invariant
    arg 0 <result_decl 0x410ecbd0 __ret
        type <record_type 0x40b50ec4 fpos<__mbstate_t> asm_written
needs-constructing type_1 type_5 BLK size <integer_cst 0x40141660 128>
unit size <integer_cst 0x40141678 16>
        .....

I.e. we say we point to struct streamposD.5127 but in reality we have a
struct fpos<__mbstate_t>D.5126 as op0 of the ADDR_EXPR.

And copy_body_r absolutely expects we're going to ignore this type-mismatch in
fold_indirect_ref.

Uh, oh - I love our type-system.

Richard.


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