Re: Convert (type *)&A into &A->field_of_type_and_offset_0.

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:
> 
> > Index: gcc/cp/class.c
> > ===================================================================
> > --- gcc/cp/class.c	(revision 123674)
> > +++ gcc/cp/class.c	(working copy)
> > @@ -522,10 +522,10 @@ convert_to_base_statically (tree expr, t
> >        pointer_type = build_pointer_type (expr_type);
> >        expr = build_unary_op (ADDR_EXPR, expr, /*noconvert=*/1);
> >        if (!integer_zerop (BINFO_OFFSET (base)))
> > -	  expr = build2 (PLUS_EXPR, pointer_type, expr,
> > -			 build_nop (pointer_type, BINFO_OFFSET (base)));
> > -      expr = build_nop (build_pointer_type (BINFO_TYPE (base)), expr);
> > -      expr = build1 (INDIRECT_REF, BINFO_TYPE (base), expr);
> > +	  expr = fold_build2 (PLUS_EXPR, pointer_type, expr,
> > +			      fold_convert (pointer_type, BINFO_OFFSET (base)));
> > +      expr = fold_convert (build_pointer_type (BINFO_TYPE (base)), expr);
> > +      expr = build_fold_indirect_ref (expr);
> >      }
> >  
> >    return expr;
> > 
> > I am testing the patch, but it seems like it was unfolded for a purpose.
> > Mark, can you enlighten me why this expression is not folded?
> > The (type)integer_cst seems particularly silly in such a common
> > construct.
> 
> I'm not sure that there was any conscious decision here.  Certainly,
> folding these things makes sense.  However, there is one thing to be
> careful about: fold is a middle-end function, so you can't pass it
> front-end trees.  But, when processing a template, there are front-end
> trees around.  So, if this function is ever called while processing a
> template body (like, to determine the type of an expression), then there
> might be front end trees in EXPR.

OK, understood.  If I add fold_build2_if_not_in_template, is there
someone later who will fold the template?

Also it seems to me that instead of (type *)&base + (type *)integer_cst
we probably can go directly into the preffered form of
&base->field_representing_the_predecestor_class_in_question
in the convert_to_base_statically?
> 
> That's why we have fold_if_not_in_template.  However, we don't have
> fold_build2_if_not_in_template, so you can't use that approach -- unless
> you want to create new functions.
> 
> I'm not sure if we can ever get to this function from within the body of
> a template.  However, if you make the change you show above, you should
> probably add a gcc_assert (!processing_template_decl) with a comment
> explaining that if we're processing a template, we shouldn't be making
> unguarded calls to the folder.  Then, if the assert trips, you may have
> to create the if_not_in_template functions, or use plain
> build2/build_nop when in a template, and fold_{build2,convert} otherwise.

OK,
I will give it a try.  I already bootstrapped/regtested the patch and it
passed, so there is good chance that gcc_assert
(!processing_template_decl) will pass too.

Thanks,
Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713