Hi All,

Ping!

I understand now why this works. The scope of the block is merged and so
all the previous declarations that would otherwise disappear are added,
even by the empty statement.

Regards

Paul


On Mon, 15 Jul 2024 at 17:10, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi All,
>
> I am not sure that I understand why this bug occurs. The regression was
> introduced by my patch that had gfc_trans_class_init_assign return
> NULL_TREE, when all the components of the default initializer are NULL.
> Note that this only afflicts scalar dummy arguments.
>
> With pr115070:
> void my_sub (struct __class_my_mod_My_type_t & restrict obs)
>   c_char fpstate.5[33];    // This disappears, when NULL is returned.
>   try
>     {
>       _gfortran_ieee_procedure_entry ((void *) &fpstate.5);
>
> With pr115348:
> void myroutine (struct __class_mymodule_Mytype_t & restrict self)
> {
>   static logical(kind=4) is_recursive.0 = 0;  // This disappears when NULL
> is returned
>   try
>     {
>       if (is_recursive.0)
>
> The fix is equally magical in that finishing build_empty_stmt seems to
> provide the backend with everything that it needs to retain these
> declarations. See the attached patch. If somebody can explain what causes
> the problem and why the patch fixes it, I would be very pleased. As far as
> I can tell, the tail end of trans_code should have been sufficient to
> handle the return of NULL_TREE.
>
> Anyway, work it does and regtests OK. OK for mainline and backporting?
>
> Regards
>
> Paul
>
>

Reply via email to