On Fri, Mar 11, 2011 at 09:01:40AM +0100, Jakub Jelinek wrote:
> Do we need to redo parts of class.c anyway? From what I understand, the
> problematic vtbl pointers are at the end of the base types and DECL_SIZE
> is set to the CLASSTYPE_AS_BASE type size, thus those pointers ought to
> be at or beyond the containing field's size.
> So, can't we simply skip subfields whose bit_position is equal or larger
> to containing field's size? Something like (works on the testcase from this
> PR, otherwise untested):
Or, in the simplify_aggr_init case where the created tree is handed
immediately to the gimplifier, there is IMHO no point in initializing
all fields to zero when the gimplifier throws that immediately away again.
So something like following works too. But I have no idea about what
the C++ FE does with all other build_zero_init calls and whether just
returning empty CONSTRUCTOR would work in those cases too or not.
--- gcc/cp/semantics.c.jj 2011-03-08 11:39:32.516389675 +0100
+++ gcc/cp/semantics.c 2011-03-11 09:27:22.340671253 +0100
@@ -3379,8 +3379,18 @@ simplify_aggr_init_expr (tree *tp)
if (AGGR_INIT_ZERO_FIRST (aggr_init_expr))
{
- tree init = build_zero_init (type, NULL_TREE,
- /*static_storage_p=*/false);
+ tree init;
+ /* Empty CONSTRUCTOR is the middle-end alternative of zero
+ initialization, so avoid creating a full CONSTRUCTOR
+ which will be thrown away immediately. */
+ if (CLASS_TYPE_P (type) || TREE_CODE (type) == ARRAY_TYPE)
+ {
+ init = build_constructor (type, NULL);
+ TREE_CONSTANT (init) = 1;
+ }
+ else
+ init = build_zero_init (type, NULL_TREE,
+ /*static_storage_p=*/false);
init = build2 (INIT_EXPR, void_type_node, slot, init);
call_expr = build2 (COMPOUND_EXPR, TREE_TYPE (call_expr),
init, call_expr);
Jakub
