Peter,
Thanks a lot for the patch.
Richard, how do you think of the patch?
(The major concern for me is:
With the current patch proposed by Peter, we will generate the call to
.DEFERRED_INIT for a variable with OPAQUE_TYPE during gimplification phase,
However, if this variable is in register, then the call to
.DEFERRED_INIT will NOT be expanded during RTL expansion phase. This
unexpanded call to .DEFERRED_INIT might cause some potential IR issue later?
If the above is a real issue, should we skip initialization for all
OPAQUE_TYPE variables even when they are in memory and can be initialized with
memset?
then we should update “is_var_need_auto_init” in gimplify.c
instead. However, the issue with this approach is, we might miss the
opportunity to initialize an OPAQUE_TYPE variable if it will be in memory?
).
Thanks.
Qing
> On Nov 29, 2021, at 3:56 PM, Peter Bergner <berg...@linux.ibm.com> wrote:
>
> Sorry for dropping the ball on testing the patch from the bugzilla!
>
> The following patch fixes the ICE reported in the bugzilla on the pre-existing
> gcc testsuite test case, bootstraps and shows no testsuite regressions
> on powerpc64le-linux. Ok for trunk?
>
> Peter
>
>
> For -ftrivial-auto-var-init=*, skip initializing the register variable if it
> is an opaque type, because CONST0_RTX(mode) is not defined for opaque modes.
>
> gcc/
> PR middle-end/103127
> * internal-fn.c (expand_DEFERRED_INIT): Skip if VAR_TYPE is opaque.
>
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 0cba95411a6..7cc0e9d5293 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -3070,6 +3070,10 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
> }
> else
> {
> + /* Skip variables of opaque types that are in a register. */
> + if (OPAQUE_TYPE_P (var_type))
> + return;
> +
> /* If this variable is in a register use expand_assignment.
> For boolean scalars force zero-init. */
> tree init;
