[Bug fortran/58043] New: Incorrect behaviour of polymorphic array

[Bug fortran/58043] New: Incorrect behaviour of polymorphic array

[frank.otto at pci dot uni-heidelberg.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043

            Bug ID: 58043
           Summary: Incorrect behaviour of polymorphic array
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: frank.otto at pci dot uni-heidelberg.de

Created attachment 30580
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30580&action=edit
test case

The following test case (also attached) produces incorrect output using
gfortran 4.8.1 (also tested: 4.8.0, 4.7.3). It uses a polymorphic array
[dofs(:)] where the polymorphic type [dof_t] contains an allocatable array
[grd(:)]. When accessed through an element of the polymorphic array, the
array descriptor of grd(:) seems wrong.

**** testcase.f90 ****

module types_m
implicit none

type,abstract :: dof_t
   integer :: gdim
   real(kind=8),allocatable :: grd(:)
   contains
   procedure(dofinit_if),deferred :: init
end type dof_t

type,extends(dof_t) :: adof_t
   contains
   procedure :: init => adofinit
end type adof_t

abstract interface
   subroutine dofinit_if(dof,gdim,xi,xf)
      import :: dof_t
      class(dof_t) :: dof
      integer      :: gdim
      real(kind=8) :: xi,xf
   end subroutine dofinit_if
end interface

contains

subroutine adofinit(dof,gdim,xi,xf)
   class(adof_t) :: dof
   integer       :: gdim,g
   real(kind=8)  :: xi,xf,dx
   dof%gdim = gdim
   allocate(dof%grd(gdim))
   dx = (xf-xi)/(gdim-1)
   do g=1,gdim
      dof%grd(g) = xi + (g-1)*dx
   enddo
   write (*,'(a)') "---- grd in adofinit ----"
   do g=1,gdim
      write (*,'(i5,f12.4)') g, dof%grd(g)
   enddo
end subroutine adofinit

end module types_m


program main
use types_m
implicit none

class(dof_t),pointer :: dofs(:)
integer              :: g

allocate(adof_t :: dofs(1))
call dofs(1)%init(17, -8.d0, 8.d0)

write (*,'(a)') "---- grd in main ----"
do g=1,dofs(1)%gdim
   write (*,'(i5,f12.4)') g, dofs(1)%grd(g)
enddo

end program main



**** gfortran version ****

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/cvos/shared/apps/gcc/4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/cvos/shared/apps/gcc/4.8.1
--enable-languages=c,c++,fortran,go,objc
--with-gmp=/cvos/shared/apps/gcc/4.8/support
--with-mpfr=/cvos/shared/apps/gcc/4.8/support
--with-mpc=/cvos/shared/apps/gcc/4.8/support
--with-isl=/cvos/shared/apps/gcc/4.8/support
--with-cloog=/cvos/shared/apps/gcc/4.8/support --disable-nls --enable-shared
--enable-threads=posix --with-system-zlib --with-tune=native
Thread model: posix
gcc version 4.8.1 (GCC) 



**** Compilation ****

$ gfortran -Wall testcase.f90 
(no messages)



**** Observed Output ****

$ ./a.out
---- grd in adofinit ----
    1     -8.0000
    2     -7.0000
    3     -6.0000
    4     -5.0000
    5     -4.0000
    6     -3.0000
    7     -2.0000
    8     -1.0000
    9      0.0000
   10      1.0000
   11      2.0000
   12      3.0000
   13      4.0000
   14      5.0000
   15      6.0000
   16      7.0000
   17      8.0000
---- grd in main ----
    1     -8.0000
    2     -1.0000
    3      6.0000
    4      0.0000
    5      0.0000
    6      0.0000
    7      0.0000
    8      0.0000
    9      0.0000
   10      0.0000
   11      0.0000
   12      0.0000
   13      0.0000
   14      0.0000
   15      0.0000
   16      0.0000
   17      0.0000



**** Expected Output ****

Both blocks of numbers should be the same.

When compiled with Intel Fortran 13.1.0, the test case produces the expected
output, and also no warnings are produced.



**** Comments ****

What also doesn't work:
* dof_t%grd as pointer instead of allocatable (same output)
* in main, dofs(:) as allocatable instead of pointer (same output)

What does work:
* Using a scalar [class(dof_t),pointer::dof] polymorphic variable instead
  of the polymorphic array.

The observed behaviour looks like something is wrong with the array
descriptor of grd(:), because this array is (in main) traversed with
a too large stride -- only every 7th element is visited. In a larger
program, this behaviour eventually leads to invalid memory access.

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043

--- Comment #2 from janus at gcc dot gnu.org ---
Here is a reduced test case, which demonstrates the same problem in a somewhat
more compact manner:


program main

  implicit none

  type :: adof_t
    real :: grd(1:2)
  end type

  class(adof_t), allocatable :: dofs(:)

  allocate(dofs(1))
  call adofinit(dofs(1))

  write (*,'(a)') "---- grd in main ----"
  write (*,'(2f12.4)') dofs(1)%grd(1), dofs(1)%grd(2)

contains

  subroutine adofinit (dof)
    class(adof_t) :: dof
    dof%grd = (/ 1., 2. /)
    write (*,'(a)') "---- grd in adofinit ----"
    write (*,'(2f12.4)') dof%grd(1), dof%grd(2)
  end subroutine adofinit

end


The output is

---- grd in adofinit ----
      1.0000      2.0000
---- grd in main ----
      1.0000      0.0000

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043

--- Comment #3 from janus at gcc dot gnu.org ---
The WRITE of the second element in main is translated into: 

_gfortran_transfer_real_write (&dt_parm.7, (real(kind=4) *) &((struct adof_t *)
dofs._data.data + (sizetype) ((dofs._data.offset + 1) * (integer(kind=8))
dofs._vptr->_size))->grd + (sizetype) dofs._vptr->_size, 4);


The problem is apparently that "grd" does not receive the correct indexing
here, but instead "dofs._vptr->_size" is added to the address, which however is
the element size of the "dofs" array and not of "grd"!

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[sacks at ucar dot edu]

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

Bill Sacks <sacks at ucar dot edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sacks at ucar dot edu

--- Comment #4 from Bill Sacks <sacks at ucar dot edu> ---
Created attachment 32926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32926&action=edit
another test case demonstrating this behavior

For what it's worth, I'm attaching another test case that demonstrates what
seems to be the same bug.

There are two subroutines, one in which the argument is declared as a 'type'
and one as a 'class'. The subroutine that uses the 'type' dummy variable
produces the correct output:

          21
          22
          23

whereas the one that uses the 'class' dummy variable produces the wrong output:

          21
           0
           0

I have confirmed this buggy behavior in gfortran 4.7.3, 4.8.2, 4.8.3 and 4.9.0.

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[vladimir.fuka at gmail dot com]

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

Vladimir Fuka <vladimir.fuka at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vladimir.fuka at gmail dot com

--- Comment #5 from Vladimir Fuka <vladimir.fuka at gmail dot com> ---
Seems to be fixed by Seems to be fixed on trunk by
https://gcc.gnu.org/ml/fortran/2015-07/msg00038.html