Thanks for the patch and chasing down the magic.
Path is ok to commit.
--
steve
On Fri, Jul 19, 2024 at 05:32:26PM +0100, Paul Richard Thomas wrote:
> 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
> >
> >
--
Steve
