[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres --- Likely fixed by revision r222361, i.e., a duplicate of pr60322. *** This bug has been marked as a duplicate of bug 60322 ***
[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 Marco van Hulten changed: What|Removed |Added CC||marco at hulten dot org --- Comment #6 from Marco van Hulten --- The problem still exists in GCC 5.4.0, which was released in June 2016. In what version is this fixed?
[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #5 from Vladimir Fuka --- Seems to be fixed by Seems to be fixed on trunk by https://gcc.gnu.org/ml/fortran/2015-07/msg00038.html
[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
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=32926action=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-01 CC||janus at gcc dot gnu.org Summary|Incorrect behaviour of |[OOP] Incorrect behaviour |polymorphic array |of polymorphic array Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I can confirm the described behavior with gfortran 4.7, 4.8 and trunk. In principle -fdump-tree-original should show what goes wrong ...
[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
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. 2. grd in main 1. 0.
[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
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!
