public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/58043] New: Incorrect behaviour of polymorphic array
@ 2013-08-01 8:59 frank.otto at pci dot uni-heidelberg.de
2013-08-01 14:41 ` [Bug fortran/58043] [OOP] " janus at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: frank.otto at pci dot uni-heidelberg.de @ 2013-08-01 8:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
2013-08-01 8:59 [Bug fortran/58043] New: Incorrect behaviour of polymorphic array frank.otto at pci dot uni-heidelberg.de
@ 2013-08-01 14:41 ` janus at gcc dot gnu.org
2013-08-01 14:49 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-01 14:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
2013-08-01 8:59 [Bug fortran/58043] New: Incorrect behaviour of polymorphic array frank.otto at pci dot uni-heidelberg.de
2013-08-01 14:41 ` [Bug fortran/58043] [OOP] " janus at gcc dot gnu.org
@ 2013-08-01 14:49 ` janus at gcc dot gnu.org
2014-06-11 17:03 ` sacks at ucar dot edu
2015-09-02 10:12 ` vladimir.fuka at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-01 14:49 UTC (permalink / raw)
To: gcc-bugs
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"!
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
2013-08-01 8:59 [Bug fortran/58043] New: Incorrect behaviour of polymorphic array frank.otto at pci dot uni-heidelberg.de
2013-08-01 14:41 ` [Bug fortran/58043] [OOP] " janus at gcc dot gnu.org
2013-08-01 14:49 ` janus at gcc dot gnu.org
@ 2014-06-11 17:03 ` sacks at ucar dot edu
2015-09-02 10:12 ` vladimir.fuka at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: sacks at ucar dot edu @ 2014-06-11 17:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array
2013-08-01 8:59 [Bug fortran/58043] New: Incorrect behaviour of polymorphic array frank.otto at pci dot uni-heidelberg.de
` (2 preceding siblings ...)
2014-06-11 17:03 ` sacks at ucar dot edu
@ 2015-09-02 10:12 ` vladimir.fuka at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: vladimir.fuka at gmail dot com @ 2015-09-02 10:12 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-09-02 10:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-01 8:59 [Bug fortran/58043] New: Incorrect behaviour of polymorphic array frank.otto at pci dot uni-heidelberg.de
2013-08-01 14:41 ` [Bug fortran/58043] [OOP] " janus at gcc dot gnu.org
2013-08-01 14:49 ` janus at gcc dot gnu.org
2014-06-11 17:03 ` sacks at ucar dot edu
2015-09-02 10:12 ` vladimir.fuka at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).