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

[Mark Mitchell <mark at codesourcery dot com>]

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.

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.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713