Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao <qing.zhao@oracle.com>]

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