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

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

> 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

(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......

(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.

(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

(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.

(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.

(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.

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.

(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).

(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.

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).

(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

(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 ***