* [Bug fortran/54874] OOP: polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
@ 2012-10-09 10:02 ` sfilippone at uniroma2 dot it
2012-10-09 10:37 ` sfilippone at uniroma2 dot it
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-09 10:02 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] OOP: polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
2012-10-09 10:02 ` [Bug fortran/54874] " sfilippone at uniroma2 dot it
@ 2012-10-09 10:37 ` sfilippone at uniroma2 dot it
2012-10-09 10:48 ` dominiq at lps dot ens.fr
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-09 10:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] OOP: polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
2012-10-09 10:02 ` [Bug fortran/54874] " sfilippone at uniroma2 dot it
2012-10-09 10:37 ` sfilippone at uniroma2 dot it
@ 2012-10-09 10:48 ` dominiq at lps dot ens.fr
2012-10-09 11:03 ` sfilippone at uniroma2 dot it
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-10-09 10:48 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] OOP: polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (2 preceding siblings ...)
2012-10-09 10:48 ` dominiq at lps dot ens.fr
@ 2012-10-09 11:03 ` sfilippone at uniroma2 dot it
2012-10-09 14:43 ` [Bug fortran/54874] [OOP] " janus at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-09 11:03 UTC (permalink / raw)
To: gcc-bugs
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......
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (3 preceding siblings ...)
2012-10-09 11:03 ` sfilippone at uniroma2 dot it
@ 2012-10-09 14:43 ` janus at gcc dot gnu.org
2012-10-09 14:46 ` sfilippone at uniroma2 dot it
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-09 14:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (4 preceding siblings ...)
2012-10-09 14:43 ` [Bug fortran/54874] [OOP] " janus at gcc dot gnu.org
@ 2012-10-09 14:46 ` sfilippone at uniroma2 dot it
2012-10-09 14:47 ` janus at gcc dot gnu.org
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-09 14:46 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (5 preceding siblings ...)
2012-10-09 14:46 ` sfilippone at uniroma2 dot it
@ 2012-10-09 14:47 ` janus at gcc dot gnu.org
2012-10-09 16:02 ` sfilippone at uniroma2 dot it
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-09 14:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (6 preceding siblings ...)
2012-10-09 14:47 ` janus at gcc dot gnu.org
@ 2012-10-09 16:02 ` sfilippone at uniroma2 dot it
2012-10-09 16:15 ` janus at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-09 16:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (7 preceding siblings ...)
2012-10-09 16:02 ` sfilippone at uniroma2 dot it
@ 2012-10-09 16:15 ` janus at gcc dot gnu.org
2012-10-09 17:13 ` janus at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-09 16:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (8 preceding siblings ...)
2012-10-09 16:15 ` janus at gcc dot gnu.org
@ 2012-10-09 17:13 ` janus at gcc dot gnu.org
2012-10-09 19:42 ` janus at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-09 17:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (9 preceding siblings ...)
2012-10-09 17:13 ` janus at gcc dot gnu.org
@ 2012-10-09 19:42 ` janus at gcc dot gnu.org
2012-10-09 22:11 ` janus at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-09 19:42 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (10 preceding siblings ...)
2012-10-09 19:42 ` janus at gcc dot gnu.org
@ 2012-10-09 22:11 ` janus at gcc dot gnu.org
2012-10-10 10:29 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-09 22:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (11 preceding siblings ...)
2012-10-09 22:11 ` janus at gcc dot gnu.org
@ 2012-10-10 10:29 ` janus at gcc dot gnu.org
2012-10-10 11:37 ` sfilippone at uniroma2 dot it
2012-10-10 11:49 ` janus at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-10 10:29 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (12 preceding siblings ...)
2012-10-10 10:29 ` janus at gcc dot gnu.org
@ 2012-10-10 11:37 ` sfilippone at uniroma2 dot it
2012-10-10 11:49 ` janus at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-10 11:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/54874] [OOP] polymorphic allocation with SOURCE
2012-10-09 9:58 [Bug fortran/54874] New: OOP: polymorphic allocation with SOURCE sfilippone at uniroma2 dot it
` (13 preceding siblings ...)
2012-10-10 11:37 ` sfilippone at uniroma2 dot it
@ 2012-10-10 11:49 ` janus at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-10 11:49 UTC (permalink / raw)
To: gcc-bugs
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 ***
^ permalink raw reply [flat|nested] 16+ messages in thread