Hi, Richard,
During the change for the 2nd version based on your previous comments, I have
the following questions need your help:
>
>> + sra_stats.subtree_deferred_init++;
>> + }
>> + else if (access->grp_to_be_debug_replaced)
>> + {
>> + /* FIXME, this part might have some issue. */
>> + tree drhs = build_debug_ref_for_model (loc, agg,
>> + access->offset - top_offset,
>> + access);
>> + gdebug *ds = gimple_build_debug_bind (get_access_replacement (access),
>> + drhs, gsi_stmt (*gsi));
>> + gsi_insert_before (gsi, ds, GSI_SAME_STMT);
>
> Would be good to fix the FIXME :-)
>
> I guess the thing we need to decide here is whether -ftrivial-auto-var-init
> should affect debug-only constructs too. If it doesn't, exmaining removed
> components in a debugger might show uninitialised values in cases where
> the user was expecting initialised ones. There would be no security
> concern, but it might be surprising.
>
> I think in principle the DRHS can contain a call to DEFERRED_INIT.
> Doing that would probably require further handling elsewhere though.
Right now, what I did is:
else if (lhs_access->grp_to_be_debug_replaced)
{
tree lhs_drepl = get_access_replacement (lhs_access);
tree init_type_node
= build_int_cst (integer_type_node, (int) init_type);
tree call = build_call_expr_internal_loc
(UNKNOWN_LOCATION, IFN_DEFERRED_INIT,
TREE_TYPE (lhs_drepl), 2, lhs_drepl, init_type_node);
gdebug *ds = gimple_build_debug_bind (lhs_drepl, call,
gsi_stmt (*gsi));
gsi_insert_before (gsi, ds, GSI_SAME_STMT);
}
Is the above matching what you suggested?
What do you mean by “further handling elsewhere”?
>
>> + is better even for pattern initialization. */
>> + return build_int_cstu (type, largevalue);
>
> I've no objection to that choice for booleans, but: booleans in some
> languages (like Ada) can have multibit precision. If we want booleans
> to be zero then it would probably be better to treat them as a separate
> case and just use build_zero_cst (type) for them.
>
> Also, the above won't work correctly for 128-bit integers: it will
> zero-initialize the upper half. It would probably be better to use
> wi::from_buffer to construct the integer instead.
You mean using wi::from_buffer to construct all the integer type (including
64-bit, 32-bit, etc.)?
I read the corresponding source codes related to “wi::from_buffer”, but still
not very clear
On how to use it for my purpose,
From my current understanding, I should use it like the following:
"
unsigned char *ptr = “0xAAAAAAAAAAAAAAAA”;
Int total_bytes = GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (type));
wide_int result = wi::from_buffer (ptr, total_bytes);
return wide_int_to_tree (type, result);
“
Is the above correct for INTEGER type?
thanks.
Qing
