[Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE

[Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE

[sfilippone at uniroma2 dot it]

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

             Bug #: 54874
           Summary: OOP: polymorphic allocation with SOURCE
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sfilippone@uniroma2.it


Created attachment 28396
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28396
test case

Hi,
I am getting the following output from the test case. It seems wrong, I do not
see why allocating the polymorphic component in p%vect(4) should change the
entries p%vect(1:3)
This may or may not be a duplicate of 54784. 

------------------------------------------------
[sfilippo@jacobi bug34]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.2/configure --prefix=/usr/local/gnu47
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
Thread model: posix
gcc version 4.7.2 (GCC) 
[sfilippo@jacobi bug34]$ gfortran -o testpolyvect testpolyvect.f90
[sfilippo@jacobi bug34]$ ./testpolyvect 

 level            1
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
 level            3
 New inner descr

 level            1
 Base inner descr
 level            2
 Base inner descr
 level            3
 Base inner descr
 level            4
 Base inner descr
------------------------------------------------------------

[Bug fortran/54874] OOP: polymorphic allocation with SOURCE

[sfilippone at uniroma2 dot it]

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

--- Comment #1 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-09 10:02:41 UTC ---
Interestingly, taking out the outer container p% makes the code work... 

-------------------------------------------------------------------
[sfilippo@jacobi bug34]$ gfortran -o poywork polywork.f90
[sfilippo@jacobi bug34]$ ./poywork 

 level            1
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
 level            3
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
 level            3
 New inner descr
 level            4
 Base inner descr

------------------------------------------------------
program testsource
  use testmod

  type(level), allocatable  :: vect(:)
  class(outer), allocatable :: outvar1, outvar2

  integer :: i,j,k,n,info

  n = 4

  allocate(outer :: outvar1)
  allocate(outer :: outvar2)
  allocate(new_inner :: outvar1%var)
  allocate(inner :: outvar2%var)


  allocate(vect(n))
  do i=1, n
    if (i<n) then 
      allocate(vect(i)%outvar,source=outvar1)
    else
      allocate(vect(i)%outvar,source=outvar2)
    end if

    write(0,*)

    do k=1,i
      write(0,*) 'level ',k
      call vect(k)%outvar%var%descr()
    end do
  end do


end program testsourc

[Bug fortran/54874] OOP: polymorphic allocation with SOURCE

[sfilippone at uniroma2 dot it]

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

--- Comment #2 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-09 10:37:13 UTC ---
And it is also a regression, as it works on 4.6.3:
-------------------------------------------------------
[sfilippo@jacobi bug34]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6.3/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
Thread model: posix
gcc version 4.6.3 (GCC) 
[sfilippo@jacobi bug34]$ gfortran -o testpolyvect testpolyvect.f90
[sfilippo@jacobi bug34]$ ./testpolyvect 

 level            1
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
 level            3
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
 level            3
 New inner descr
 level            4
 Base inner descr

[Bug fortran/54874] OOP: polymorphic allocation with SOURCE

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-10-09 10:48:30 UTC ---
> And it is also a regression, as it works on 4.6.3: ...

Well, this may be more complicated. On x86_64-apple-darwin10, compiling the
attached test with 4.6.3 gives:

[macbook] f90/bug% a.out

 level            1
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
 level            3
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
 level            3
 New inner descr
 level            4
 Base inner descr
a.out(97528) malloc: *** error for object 0x100201030: pointer being freed was
not allocated
*** set a breakpoint in malloc_error_break to debug

while I get the same result minus the error with 4.7.2 and trunk.

For the test in comment #1, I always get

[macbook] f90/bug% gfortran-fsf-4.6 pr54874_1.f90 -g
Undefined symbols:
  "___testmod_MOD___vtab_testmod_Outer", referenced from:
      _MAIN__ in cclihViD.o
      _MAIN__ in cclihViD.o
      _MAIN__ in cclihViD.o
      _MAIN__ in cclihViD.o
      _MAIN__ in cclihViD.o
  "___testmod_MOD___vtab_testmod_Inner", referenced from:
      _MAIN__ in cclihViD.o
  "___testmod_MOD___vtab_testmod_New_inner", referenced from:
      _MAIN__ in cclihViD.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

[Bug fortran/54874] OOP: polymorphic allocation with SOURCE

[sfilippone at uniroma2 dot it]

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

--- Comment #4 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-09 11:03:10 UTC ---
(In reply to comment #3)
> > And it is also a regression, as it works on 4.6.3: ...
> 
> Well, this may be more complicated. On x86_64-apple-darwin10, compiling the
> attached test with 4.6.3 gives:
> 

Something is very fishy here......

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-09
     Ever Confirmed|0                           |1

--- Comment #5 from janus at gcc dot gnu.org 2012-10-09 14:42:48 UTC ---
(In reply to comment #0)
> I am getting the following output from the test case. It seems wrong, I do not
> see why allocating the polymorphic component in p%vect(4) should change the
> entries p%vect(1:3)
> This may or may not be a duplicate of 54784. 

Yes, this is surely a duplicate of PR54784, which is confirmed by the fact that
the patch given there also fixes the behavior here.

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[sfilippone at uniroma2 dot it]

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

--- Comment #6 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-09 14:46:15 UTC ---
(In reply to comment #5)
> (In reply to comment #0)
> > I am getting the following output from the test case. It seems wrong, I do not
> > see why allocating the polymorphic component in p%vect(4) should change the
> > entries p%vect(1:3)
> > This may or may not be a duplicate of 54784. 
> 
> Yes, this is surely a duplicate of PR54784, which is confirmed by the fact that
> the patch given there also fixes the behavior here.

Great news! 
Thanks
Salvatore

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2012-10-09 14:47:38 UTC ---
(In reply to comment #3)
> Well, this may be more complicated. On x86_64-apple-darwin10, compiling the
> attached test with 4.6.3 gives:
> [...]
> a.out(97528) malloc: *** error for object 0x100201030: pointer being freed was
> not allocated
> *** set a breakpoint in malloc_error_break to debug
> 
> while I get the same result minus the error with 4.7.2 and trunk.
> 
> For the test in comment #1, I always get
> 
> [macbook] f90/bug% gfortran-fsf-4.6 pr54874_1.f90 -g
> Undefined symbols:
>   "___testmod_MOD___vtab_testmod_Outer", referenced from:
>       _MAIN__ in cclihViD.o
>       _MAIN__ in cclihViD.o
>       _MAIN__ in cclihViD.o
>       _MAIN__ in cclihViD.o
>       _MAIN__ in cclihViD.o
>   "___testmod_MOD___vtab_testmod_Inner", referenced from:
>       _MAIN__ in cclihViD.o
>   "___testmod_MOD___vtab_testmod_New_inner", referenced from:
>       _MAIN__ in cclihViD.o
> ld: symbol(s) not found

So, the only additional problems here are these errors on darwin. While the
first one only seems to occur with 4.6, the second one also persists in 4.7 and
trunk, if I get you right.

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[sfilippone at uniroma2 dot it]

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

--- Comment #8 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-09 16:02:35 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #0)
> > > I am getting the following output from the test case. It seems wrong, I do not
> > > see why allocating the polymorphic component in p%vect(4) should change the
> > > entries p%vect(1:3)
> > > This may or may not be a duplicate of 54784. 
> > 
> > Yes, this is surely a duplicate of PR54784, which is confirmed by the fact that
> > the patch given there also fixes the behavior here.
> 
> Great news! 
> Thanks
> Salvatore

I can confirm that patching my 4.7.2 source tree fixes not just the test case
but also the code it was derived from, on x86_64-linux.

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2012-10-09 16:15:24 UTC ---
(In reply to comment #8)
> I can confirm that patching my 4.7.2 source tree fixes not just the test case
> but also the code it was derived from, on x86_64-linux.

Very good, thank you. We definitely need to backport this fix to the 4.7
branch. However, as pointed out by Mikael, the patch I posted is incomplete and
can still fail in certain cases.

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2012-10-09 17:13:05 UTC ---
Ok, I just tried this one on x86_64-apple-darwin11.3.0, where I have three
(non-release) versions of gfortran lying around:

gcc-Version 4.6.0 20110202 (experimental) [trunk revision 169590] (GCC)
gcc-Version 4.7.0 20111231 (experimental) [trunk revision 182754] (GCC) 
gcc-Version 4.8.0 20120409 (experimental) [trunk revision 186243] (GCC)

All three cleanly compile comment 0, while only the 4.7 version fails to
compile commment 1 with some ICE:

c1.f90: In Funktion »testsource«:
c1.f90:58:0: interner Compiler-Fehler: Segmentation fault: 11

This is obviously different from the compile-time problems that Salvatore
reported in comment 3, and it may just be due to my version being pre-release.

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org 2012-10-09 19:41:41 UTC ---
(In reply to comment #10)
> Ok, I just tried this one on x86_64-apple-darwin11.3.0, where I have three
> (non-release) versions of gfortran lying around:
> 
> gcc-Version 4.6.0 20110202 (experimental) [trunk revision 169590] (GCC)
> gcc-Version 4.7.0 20111231 (experimental) [trunk revision 182754] (GCC) 
> gcc-Version 4.8.0 20120409 (experimental) [trunk revision 186243] (GCC)

To expand on that, the 4.6 version at runtime produces the following on comment
0 and comment 1:

a.out(356) malloc: *** error for object 0x7ffc8ac01840: pointer being freed was
not allocated
*** set a breakpoint in malloc_error_break to debug

... which is apparently the same problem that Salvatore reported.


Compiling comment 0 with the 4.7 version produces the following at runtime:

 level            1
 New inner descr

 level            1
 New inner descr
 level            2
 New inner descr
a.out(399) malloc: *** error for object 0x7f8340401840: pointer being freed was
not allocated
*** set a breakpoint in malloc_error_break to debug

Backtrace for this error:
0   libgfortran.3.dylib                 0x00000001019c0d97
_gfortrani_show_backtrace + 55
1   ???                                 0x00007fff615f2da0 0x0 +
140734827015584
2   libsystem_c.dylib                   0x00007fff94b8d84c free + 389
3   a.out                               0x00000001019b7fec
__testmod_MOD___copy_testmod_Outer + 94
4   a.out                               0x00000001019b86c9 MAIN__ + 1703
5   a.out                               0x00000001019b8b6e main + 54
6   a.out                               0x00000001019b7e94 start + 52


4.8 does not show any runtime errors with comment 0 or comment 1 (except for
the 'wrong' output for comment 0).

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org 2012-10-09 22:10:59 UTC ---
(In reply to comment #10)
> All three cleanly compile comment 0, while only the 4.7 version fails to
> compile commment 1 with some ICE:
> 
> c1.f90: In Funktion »testsource«:
> c1.f90:58:0: interner Compiler-Fehler: Segmentation fault: 11

This goes away when updating to

gcc-Version 4.7.3 20121009 (prerelease) [gcc-4_7-branch revision 192273] (GCC) 

just as the runtime error in comment 11.

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org 2012-10-10 10:29:27 UTC ---
Salvatore, I would say we can close this PR (as a duplicate of PR54784), unless
the runtime error with 4.6 on darwin is a regression (which I currently can not
check).

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[sfilippone at uniroma2 dot it]

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

--- Comment #14 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-10 11:36:45 UTC ---
(In reply to comment #13)
> Salvatore, I would say we can close this PR (as a duplicate of PR54784), unless
> the runtime error with 4.6 on darwin is a regression (which I currently can not
> check).

Fine with me. I presume it should make its way into 4.7.3, right? 
Thanks 
Salvatore

[Bug fortran/54874] [OOP] polymorphic allocation with SOURCE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #15 from janus at gcc dot gnu.org 2012-10-10 11:49:02 UTC ---
(In reply to comment #14)
> > Salvatore, I would say we can close this PR (as a duplicate of PR54784),
> 
> Fine with me.

Alright, doing so.


> I presume it should make its way into 4.7.3, right? 

Since 4.7.2 has only recently been released and we have a draft patch already,
I am pretty sure it will.

*** This bug has been marked as a duplicate of bug 54784 ***