[Bug fortran/99308] New: [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array

[Bug fortran/99308] New: [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array

[8718033x at gmail dot com]

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

            Bug ID: 99308
           Summary: [OOP] passing array of object as class(TYPE) to
                    procedure  leads to incorrect length of array
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: 8718033x at gmail dot com
  Target Milestone: ---

Created attachment 50269
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50269&action=edit
example code for generating error

If both function and subroutine takes polymorphic arrays argument, 
then the leading array(the first appear array's) length
become following array's length.

This is my first bug report. so if something wrong with it, please let me know.

version: 10.2.0
linux version: arch linux 5.11.1-arch1-1 
given option: -Og 

Example code attached.
Extra-description:
subroutine err_ver(spcs, fuel)
class(Specie) :: spcs(8), fuel(2)
...
end subroutine 

subroutine working_ver(spcs, fuel)
type(Specie) :: spcs(8), fuel(2)
..
end subroutine 

For both version, we expect that 
1. size(spcs) == 8
2. size(fuel) == 2
are true.
But, what I've got was a 8, 8 for the err_ver.
if you change the order of spcs and fuel, then you will get 2, 2

[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2021-02-28
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmes since at least GCC7.

[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I think there are two errors:

(a) The value can be simplified at compile time as the size (8 or 2) is known
at compile time, but isn't.

I wonder whether this only a problem for 'size' or also for 'ubound','lbound'
or when doing
  var(:)%idx = 0  – for the bounds of the generated do loop.


(b) The run-time version is wrong.

In my dump, (and output '2 2') I see for either variable

      parm.10.span = spcs->_vptr->_size;
      parm.10.dtype = {.elem_len=4, .rank=1, .type=5};
      D.3995 = stride.5;
      parm.10.dim[0].lbound = 1;
      parm.10.dim[0].ubound = 2;
      parm.10.dim[0].stride = NON_LVALUE_EXPR <D.3995>;
      parm.10.data = 0B;
      parm.10.offset = -NON_LVALUE_EXPR <D.3995>;
      D.3996 = &parm.10;
      D.3997 = (integer(kind=4)) MAX_EXPR <(D.3996->dim[0].ubound -
D.3996->dim[0].lbound) + 1, 0>;


Obviously, 'ubound = 2' is only valid for 'fuel' and not for 'spcs'.

[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
Possible duplicate of PR57590, which has lengthy explanations.