[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.3                         |9.4

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 9.3.0 has been released, adjusting target milestone.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |---

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 55294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55294&action=edit
WIP patch

The attached WIP patch fixes the issue for optional arguments of intrinsic type
except CHARACTER, but does not yet handle derived types.  Regtests OK.

Enabling derived types does not work when they occur in an array constructor,
and the code would ICE on empty constructors of derived type.

I haven't understood yet how (and why) temporaries are generated for
procedure arguments even when it is known at compile-time that these have
size zero.  I'd appreciate input from others.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|anlauf at gmx dot de               |
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #8)
> 
> I haven't understood yet how (and why) temporaries are generated for
> procedure arguments even when it is known at compile-time that these have
> size zero.  I'd appreciate input from others.

I think temporaries in this case come from the scalarizer, which is known to
generate superfluous temporaries with array constructors.  See
trans_array_constructor.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 55296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55296&action=edit
Another way to fix this problem

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #9)
> (In reply to anlauf from comment #8)
> > 
> > I haven't understood yet how (and why) temporaries are generated for
> > procedure arguments even when it is known at compile-time that these have
> > size zero.  I'd appreciate input from others.
> 
> See trans_array_constructor.

Actually, your patch is already touching that function.
I'm afraid this is an area nobody (well, nobody but you) dares touching.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #8) 
> Enabling derived types does not work when they occur in an array constructor,
> and the code would ICE on empty constructors of derived type.
> 

Looking at the code, I couldn't foresee where the ICE would happen, so I tried
it myself.
I see no ICE here.

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 04b5e30b96a..4fd3fb65a54 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -2941,10 +2941,6 @@ trans_array_constructor (gfc_ss * ss, locus * where)
         from constructor only for meaningful shape.  */
       bool zero_sized = zero_sized_array_p (expr);

-      /* FIXME: constant array constructors for DT have some issues...  */
-      if (expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
-       zero_sized = false;
-
       if (!zero_sized)
        nelem = gfc_constant_array_constructor_p (c);


program test
  implicit none
  type :: t
    integer :: c
  end type t
  integer :: m(0)
  integer, allocatable :: n(:)
  call i
  call i(m)
  call i(n)
  allocate (n(0))
  call i(n)
  call i([integer::])       ! expect "optional argument present: T"
  call i([1])
  call j([t::])
contains
  subroutine i(str)
    integer, dimension(:), optional, intent(in) :: str
    write(6,*) 'optional argument present:', present(str)
  end subroutine i
  subroutine j(str)
    type(t), dimension(:), optional, intent(in) :: str
    write(6,*) 'optional argument present:', present(str)
  end subroutine j
end program

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #12)
> (In reply to anlauf from comment #8) 
> > Enabling derived types does not work when they occur in an array constructor,
> > and the code would ICE on empty constructors of derived type.
> > 
> 
> Looking at the code, I couldn't foresee where the ICE would happen, so I
> tried it myself.
> I see no ICE here.

I got an ICE with pointer_check_14.f90 and realloc_on_assign_18.f90
which have an empty DT with no component.

I guess it's all about zeros...

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #14 from anlauf at gcc dot gnu.org ---
Created attachment 55297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55297&action=edit
Draft testcase

This testcase tries to probe many different paths for real array ctors.
I have similar testcases for character and DT which need more work.

Will look at your approach later.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #14)
> Will look at your approach later.

For the draft testcase, your patch seems to handle the explicit temporaries,
but there is a runtime error (memory corruption?) for some of the cases
with array ctors.

Your patch also seems to fix (at first glance) the character case as well
as type, so this appears to be the right direction.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #16 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #13)
> (In reply to Mikael Morin from comment #12)
> > (In reply to anlauf from comment #8) 
> > > Enabling derived types does not work when they occur in an array constructor,
> > > and the code would ICE on empty constructors of derived type.
> > > 
> > 
> > Looking at the code, I couldn't foresee where the ICE would happen, so I
> > tried it myself.
> > I see no ICE here.
> 
> I got an ICE with pointer_check_14.f90 and realloc_on_assign_18.f90
> which have an empty DT with no component.
> 
They work here.  I must be doing something stupidly wrong.
My compiler is a bit outdated, but not that much:
GNU Fortran (GCC) 14.0.0 20230529 (experimental)

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #17 from Mikael Morin <mikael at gcc dot gnu.org> ---
Looking further at the implementation of gfc_trans_allocate_array_storage, the
size vs elem_size dance can be removed from my patch, as size is almost unused
in the onstack case.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55296|0                           |1
        is obsolete|                            |

--- Comment #18 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 55300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55300&action=edit
Alternative patch v2

(In reply to Mikael Morin from comment #17)
> Looking further at the implementation of gfc_trans_allocate_array_storage,
> the size vs elem_size dance can be removed from my patch, as size is almost
> unused in the onstack case.

Updated patch attached.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #19 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #15)
> 
> Your patch also seems to fix (at first glance) the character case as well
> as type, so this appears to be the right direction.

Yet, your patch identifies a bug in trans_array_constructor.
Not sure whether that bug can also be visible in a different case.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #18)
> Created attachment 55300 [details]
> Alternative patch v2

This patch fails for me on several occasions including the testsuite.
I guess the logic was intended as follows:

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e1c75e9fe02..ebadda20004 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,

   desc = info->descriptor;
   info->offset = gfc_index_zero_node;
-  if (size == NULL_TREE || integer_zerop (size))
+  if (size == NULL_TREE)
     {
       /* A callee allocated array.  */
       gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);
@@ -1129,6 +1129,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,
       onstack = !dynamic && initial == NULL_TREE
                         && (flag_stack_arrays
                             || gfc_can_put_var_on_stack (size));
+      onstack = onstack && !integer_zerop (size);

       if (onstack)
        {


This seems to work on the present cases and regtests almost cleanly, with
the only exception being gfortran.dg/pr69955.f90, which needs an adjustment
of the scan-tree-dump pattern due to an additional __builtin_malloc.

I am beginning to think that there are multiple issues exhibited here: a
wrong-code issue, which is fixed by the above, and a missed-optimization,
which I tried to address with my initial patch.

If the above patch turns out to fix the wrong-code issue safely, I would
like to prepare it for mainline, and if it survives there for some time,
consider a backport to 13-branch in time for 13.2 release.

The missed optimization with superfluous temporaries could then be split
off to a separate PR and addressed only for future (14+) branches.

I'll prepare additional testcases for character and type and see if the above
patch is sufficient.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #21 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #20)
> 
> This patch fails for me on several occasions including the testsuite.
> I guess the logic was intended as follows:
> 
Well, not really, it seems wasteful to use the heap for something known to be
useless anyway.
But I agree that your variant is probably safer.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #22 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #20)
> (In reply to Mikael Morin from comment #18)
> > Created attachment 55300 [details]
> > Alternative patch v2
> 
> This patch fails for me on several occasions including the testsuite.

Obviously the stack shouldn't be used if the array can grow dynamically
(dynamic == true).
So the patch could be simplified further:

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1c7ea900ea1..cc1dddbeb33 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,

   desc = info->descriptor;
   info->offset = gfc_index_zero_node;
-  if (size == NULL_TREE || integer_zerop (size))
+  if (size == NULL_TREE)
     {
       /* A callee allocated array.  */
       gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #23 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #22)
> 
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 1c7ea900ea1..cc1dddbeb33 100644
> --- a/gcc/fortran/trans-array.cc
> +++ b/gcc/fortran/trans-array.cc
> @@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
> stmtblock_t * post,
>  
>    desc = info->descriptor;
>    info->offset = gfc_index_zero_node;
> -  if (size == NULL_TREE || integer_zerop (size))
> +  if (size == NULL_TREE)
>      {
>        /* A callee allocated array.  */
>        gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);

This regresses on pr108065.f90 (that's a few extra analyzer warnings),
and on pr69955.f90 (that's one extra __builtin_malloc).

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #24 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #23)
> 
> This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> and on pr69955.f90 (that's one extra __builtin_malloc).

This removes the regressions.  Not fully retested again.

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1c7ea900ea1..7ae7eacca0b 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,

   desc = info->descriptor;
   info->offset = gfc_index_zero_node;
-  if (size == NULL_TREE || integer_zerop (size))
+  if (size == NULL_TREE || (dynamic && integer_zerop (size)))
     {
       /* A callee allocated array.  */
       gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #25 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #24)
> (In reply to Mikael Morin from comment #23)
> > 
> > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > and on pr69955.f90 (that's one extra __builtin_malloc).
> 
> This removes the regressions.  Not fully retested again.
> 
Comment #23 is probably the more correct one.
Comment #24 works because of the double temporary.  Even if the first temporary
has NULL data component, the second one uses malloc unconditionally to set
data, and the argument is seen as present.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55297|0                           |1
        is obsolete|                            |

--- Comment #26 from anlauf at gcc dot gnu.org ---
Created attachment 55314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55314&action=edit
Revised/extended testcase

Testcase extended to check more code variations for intrinsic non-character
types and for empty derived type.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #27 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #25)
> (In reply to Mikael Morin from comment #24)
> > (In reply to Mikael Morin from comment #23)
> > > 
> > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > 
> > This removes the regressions.  Not fully retested again.
> > 
> Comment #23 is probably the more correct one.
> Comment #24 works because of the double temporary.  Even if the first
> temporary has NULL data component, the second one uses malloc
> unconditionally to set data, and the argument is seen as present.

Are you sure that you haven't mixed up those two?

When trying with my extended testcase, and looking at the tree dump,
I see a double temporary for the call

    call i ([real:: y])

where the data pointer to the first allocation is clobbered later.
So I would rather go with the version from comment #24.

The said line is actually very old code ... ;-)

If you don't object, I'll package the patch with testcases and submit.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #28 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #27)
> (In reply to Mikael Morin from comment #25)
> > (In reply to Mikael Morin from comment #24)
> > > (In reply to Mikael Morin from comment #23)
> > > > 
> > > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > > 
> > > This removes the regressions.  Not fully retested again.
> > > 
> > Comment #23 is probably the more correct one.
> > Comment #24 works because of the double temporary.  Even if the first
> > temporary has NULL data component, the second one uses malloc
> > unconditionally to set data, and the argument is seen as present.
> 
> Are you sure that you haven't mixed up those two?
> 
> When trying with my extended testcase, and looking at the tree dump,
> I see a double temporary for the call
> 
>     call i ([real:: y])
> 
> where the data pointer to the first allocation is clobbered later.
> So I would rather go with the version from comment #24.
> 
Let's rephrase:
When (or rather if) we manage to remove the double temporary, we'll regress
with comment #24, not with comment #23.
The reallocation remains by the way, it's only pushed one step away.
Try this for example:

    call i([real:: y, y])


> If you don't object, I'll package the patch with testcases and submit.

No problem, I think we are safe with the second temporary.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #29 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #28)
> (In reply to anlauf from comment #27)
> > (In reply to Mikael Morin from comment #25)
> > > (In reply to Mikael Morin from comment #24)
> > > > (In reply to Mikael Morin from comment #23)
> > > > > 
> > > > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > > > 
> > > > This removes the regressions.  Not fully retested again.
> > > > 
> > > Comment #23 is probably the more correct one.
> > > Comment #24 works because of the double temporary.  Even if the first
> > > temporary has NULL data component, the second one uses malloc
> > > unconditionally to set data, and the argument is seen as present.
> > 
> > Are you sure that you haven't mixed up those two?
> > 
> > When trying with my extended testcase, and looking at the tree dump,
> > I see a double temporary for the call
> > 
> >     call i ([real:: y])
> > 
> > where the data pointer to the first allocation is clobbered later.
> > So I would rather go with the version from comment #24.
> > 
> Let's rephrase:
> When (or rather if) we manage to remove the double temporary, we'll regress
> with comment #24, not with comment #23.
> The reallocation remains by the way, it's only pushed one step away.
> Try this for example:
> 
>     call i([real:: y, y])

I do see the reallocation, but in the case of the patch in #24 it is a
realloc of a NULL, which is well-defined nowadays.

But I do not see a regression.  On the contrary, every else seems unchanged.

>  
> > If you don't object, I'll package the patch with testcases and submit.
> 
> No problem, I think we are safe with the second temporary.

Besides the issue with one or two temporaries, is there anything else?

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #30 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #29)
> (In reply to Mikael Morin from comment #28)
> > (In reply to anlauf from comment #27)
> > > (In reply to Mikael Morin from comment #25)
> > > > (In reply to Mikael Morin from comment #24)
> > > > > (In reply to Mikael Morin from comment #23)
> > > > > > 
> > > > > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > > > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > > > > 
> > > > > This removes the regressions.  Not fully retested again.
> > > > > 
> > > > Comment #23 is probably the more correct one.
> > > > Comment #24 works because of the double temporary.  Even if the first
> > > > temporary has NULL data component, the second one uses malloc
> > > > unconditionally to set data, and the argument is seen as present.
> > > 
> > > Are you sure that you haven't mixed up those two?
> > > 
> > > When trying with my extended testcase, and looking at the tree dump,
> > > I see a double temporary for the call
> > > 
> > >     call i ([real:: y])
> > > 
> > > where the data pointer to the first allocation is clobbered later.
> > > So I would rather go with the version from comment #24.
> > > 
> > Let's rephrase:
> > When (or rather if) we manage to remove the double temporary, we'll regress
> > with comment #24, not with comment #23.
> > The reallocation remains by the way, it's only pushed one step away.
> > Try this for example:
> > 
> >     call i([real:: y, y])
> 
> I do see the reallocation, but in the case of the patch in #24 it is a
> realloc of a NULL, which is well-defined nowadays.
> 
> But I do not see a regression.  On the contrary, every else seems unchanged.
> 
> >  
> > > If you don't object, I'll package the patch with testcases and submit.
> > 
> > No problem, I think we are safe with the second temporary.
> 
> Besides the issue with one or two temporaries, is there anything else?

Now that I think again, I'm not even sure we would regress.
My concern was that the data would remain NULL after the realloc(NULL, 0), and
the argument would not be seen as present.  With the second temporary, all is
well.

That's all there is.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #31 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #30)
> Now that I think again, I'm not even sure we would regress.
> My concern was that the data would remain NULL after the realloc(NULL, 0),
> and the argument would not be seen as present.  With the second temporary,
> all is well.

OK, I'll add that variant to the testcases.  Better safe than sorry... ;-)

> That's all there is.

OK, I'll then package it.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #32 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-June/059435.html

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #33 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:c1691509e5a8875f36c068a5ea101bf13f140948

commit r14-1795-gc1691509e5a8875f36c068a5ea101bf13f140948
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Mon Jun 12 23:08:48 2023 +0200

    Fortran: fix passing of zero-sized array arguments to procedures [PR86277]

    gcc/fortran/ChangeLog:

            PR fortran/86277
            * trans-array.cc (gfc_trans_allocate_array_storage): When passing a
            zero-sized array with fixed (= non-dynamic) size, allocate
temporary
            by the caller, not by the callee.

    gcc/testsuite/ChangeLog:

            PR fortran/86277
            * gfortran.dg/zero_sized_14.f90: New test.
            * gfortran.dg/zero_sized_15.f90: New test.

    Co-authored-by: Mikael Morin <mikael@gcc.gnu.org>

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #34 from anlauf at gcc dot gnu.org ---
The missed-optimization (duplicate temporaries) is now tracked in pr110241.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

--- Comment #35 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:74ef4221b5ebb1122349ad48422ddc40e98c267d

commit r13-7502-g74ef4221b5ebb1122349ad48422ddc40e98c267d
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Mon Jun 12 23:08:48 2023 +0200

    Fortran: fix passing of zero-sized array arguments to procedures [PR86277]

    gcc/fortran/ChangeLog:

            PR fortran/86277
            * trans-array.cc (gfc_trans_allocate_array_storage): When passing a
            zero-sized array with fixed (= non-dynamic) size, allocate
temporary
            by the caller, not by the callee.

    gcc/testsuite/ChangeLog:

            PR fortran/86277
            * gfortran.dg/zero_sized_14.f90: New test.
            * gfortran.dg/zero_sized_15.f90: New test.

    Co-authored-by: Mikael Morin <mikael@gcc.gnu.org>
    (cherry picked from commit c1691509e5a8875f36c068a5ea101bf13f140948)

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |13.2
             Status|ASSIGNED                    |RESOLVED

--- Comment #36 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14, and backported to 13-branch for 13.2.

The backport required a backport of r14-90 concerning some poor scan patterns.

Closing.