[Bug fortran/102641] New: Bogus error for intent(out) dummy that is a polymorphic assumed-rank array

[Bug fortran/102641] New: Bogus error for intent(out) dummy that is a polymorphic assumed-rank array

[sandra at gcc dot gnu.org]

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

            Bug ID: 102641
           Summary: Bogus error for intent(out) dummy that is a
                    polymorphic assumed-rank array
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

A trivial subroutine with a intent(out) dummy that is a polymorphic
assumed-rank array...

module m

contains
    subroutine s1 (x, y)
      class(*) :: x(..)
      class(*), intent (out) :: y(..)
    end subroutine

end module

...incorrectly produces a compilation error:

unlimited1.f90:4:23:

    4 |     subroutine s1 (x, y)
      |                       1
Error: Assumed-rank variable y at (1) may only be used as actual argument

This error is arising from references to the intent(out) argument in the
automatically-generated deallocation and initialization code.  Probably some
flag needs to be added to the references in that code to suppress the warning,
which is coming from resolve_variable in resolve.c.

Of course runtime testing is needed as well to ensure that the generated
initialization code DTRT with assumed-rank arrays -- it's obviously never been
tested.  In fact, I wonder if the initialization code generator is even
equipped to handle arrays whose rank is unknown at compile time.  (I'm not
familiar with the code to implement it, but I see a loop nest coming out of the
front end for fixed-rank arrays.)

I ran into this error while working on PR 54753 (diagnostic for C839 involving
assumed-size actual arguments passed to assumed-rank dummies), but it's a
different issue unrelated to invalid calls, so I'm giving it its own issue. 
The patch Tobias already committed that was tagged PR 54753 only fixed
interface declarations by suppressing the unused initialization code entirely,
as a workaround to unblock testing of the actual fix for PR 54753.

[Bug fortran/102641] Bogus error for intent(out) dummy that is a polymorphic assumed-rank array

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The issue with the code in comment 0 is that GCC has in resolve.c's
resolve_symbol:

  if (sym->ts.type == BT_DERIVED
      ....
      if ((!a->save && !a->dummy && !a->pointer
          ...
        apply_default_init (sym);

and likewise a few lines below for BT_CLASS.

As there is now code which references the dummy variable, the error
  Assumed-rank variable y at (1) may only be used as actual argument
is shown.

 * * *

And in a similar vain, the following produces an ICE. It is quite similar
but as it uses an allocatable component, the code is generated after
resolving the symbols - such that an ICE and not a bogus error is the
result:

module m
  implicit none (type, external)
  type t
    integer, allocatable :: x
  end type t
contains
  subroutine foo(x)
    type(t), intent(out) :: x(..)
  end
end


Note: C839 (→ PR 54753) prevents some odd corner cases (involving assumed size
arrays).

One way to handle it would be to handle it in the caller and not in the callee.
However, this still requires support for assumed-rank as the following should
be valid:

  subroutine foo(x)
    type(t), intent(out) :: x(..)
    ...
  subroutine bar(y)
    type(t), allocatable :: y(..)
    call foo(x)

(y has to be either allocatable or a pointer in order not to violate C839.)

As the issue with finalization, polymorphism, allocatable components and
default initialization cannot occur with BIND(C), there is no issue if foo or
bar is BIND(C).

[Bug fortran/102641] Bogus error for intent(out) dummy that is a polymorphic assumed-rank array

[sandra at gcc dot gnu.org]

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

--- Comment #2 from sandra at gcc dot gnu.org ---
I was thinking that for assumed-rank the front end should probably just emit a
call to a library support function in the callee, instead of whatever it is
doing now to try to deallocate/initialize the array.  That would also fix the
bogus warning, since passing an assumed-rank argument to another function that
expects one is permitted.

[Bug fortran/102641] Bogus error for intent(out) dummy that is a polymorphic assumed-rank array

[sandra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641
Bug 102641 depends on bug 102729, which changed state.

Bug 102729 Summary: Assumed rank: ICE when passing noncontiguous to CONTIGUOUS assume rank (assumed-rank loop handling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102729

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE