* [Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
@ 2012-10-02 21:52 ` janus at gcc dot gnu.org
2012-10-02 22:15 ` jkozdon at gmail dot com
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-02 21:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Keywords| |wrong-code
Last reconfirmed| |2012-10-02
CC| |janus at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|[oop] allocation of |[OOP] allocation of
|extended types with |extended types with
|polymorphic allocatable |polymorphic allocatable
|members |members
--- Comment #1 from janus at gcc dot gnu.org 2012-10-02 21:51:49 UTC ---
Thanks for reporting this. I can reproduce it with 4.7 and trunk. Here is a
reduced test case:
program bug
implicit none
type :: block
real, allocatable :: fields
end type
type :: list
class(block),allocatable :: B
end type
type :: domain
type(list),dimension(2) :: L
end type
type(domain) :: d
type(block) :: b1
allocate(d%L(2)%B,source=b1)
end program bug
This fails at runtime with:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7F379D1FDA97
#1 0x7F379D1FE074
#2 0x7F379C72ED9F
#3 0x400804 in __copy_bug_Block at bug.f90:9
#4 0x40097C in bug at bug.f90:19 (discriminator 2)
Segmentation fault
valgrind shows:
==11046== Invalid read of size 8
==11046== at 0x400804: __copy_bug_Block (bug.f90:9)
==11046== by 0x40097C: MAIN__ (bug.f90:19)
==11046== by 0x400A88: main (bug.f90:21)
==11046== Address 0x0 is not stack'd, malloc'd or (recently) free'd
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
2012-10-02 21:52 ` [Bug fortran/54784] [OOP] " janus at gcc dot gnu.org
@ 2012-10-02 22:15 ` jkozdon at gmail dot com
2012-10-02 22:36 ` janus at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jkozdon at gmail dot com @ 2012-10-02 22:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #2 from Jeremy Kozdon <jkozdon at gmail dot com> 2012-10-02 22:14:57 UTC ---
So there is actually two different bugs, one is the invalid memory reference
which happens when you don't allocate in order.
There is a second, the one I was really trying to report, and that's when
allocating in my original example type(block1d) before type(block2d), namely
the call
call d%addBlock(1,b1)
call d%addBlock(2,b2)
as opposed to
call d%addBlock(1,b2)
call d%addBlock(2,b1)
This gives the error:
a.out(4678) malloc: *** error for object 0x7fff82ec09be: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT: Process abort signal.
Backtrace for this error:
#0 0x100004fbe
#1 0x1000056d4
#2 0x7fff82f1f1b9
Abort trap
(In reply to comment #1)
> Thanks for reporting this. I can reproduce it with 4.7 and trunk. Here is a
> reduced test case:
>
> program bug
> implicit none
>
> type :: block
> real, allocatable :: fields
> end type
>
> type :: list
> class(block),allocatable :: B
> end type
>
> type :: domain
> type(list),dimension(2) :: L
> end type
>
> type(domain) :: d
> type(block) :: b1
>
> allocate(d%L(2)%B,source=b1)
>
> end program bug
>
>
>
> This fails at runtime with:
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
>
> Backtrace for this error:
> #0 0x7F379D1FDA97
> #1 0x7F379D1FE074
> #2 0x7F379C72ED9F
> #3 0x400804 in __copy_bug_Block at bug.f90:9
> #4 0x40097C in bug at bug.f90:19 (discriminator 2)
> Segmentation fault
>
>
> valgrind shows:
>
> ==11046== Invalid read of size 8
> ==11046== at 0x400804: __copy_bug_Block (bug.f90:9)
> ==11046== by 0x40097C: MAIN__ (bug.f90:19)
> ==11046== by 0x400A88: main (bug.f90:21)
> ==11046== Address 0x0 is not stack'd, malloc'd or (recently) free'd
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
2012-10-02 21:52 ` [Bug fortran/54784] [OOP] " janus at gcc dot gnu.org
2012-10-02 22:15 ` jkozdon at gmail dot com
@ 2012-10-02 22:36 ` janus at gcc dot gnu.org
2012-10-02 22:46 ` janus at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-02 22:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #3 from janus at gcc dot gnu.org 2012-10-02 22:35:57 UTC ---
(In reply to comment #2)
> So there is actually two different bugs
Or the two different errors you are seeing are really due to the same
underlying problem. I'm not quite sure about that yet, but I already have a
suspicion ...
> one is the invalid memory reference
> which happens when you don't allocate in order.
>
> There is a second, the one I was really trying to report, and that's when
> allocating in my original example type(block1d) before type(block2d), namely
> the call
> call d%addBlock(1,b1)
> call d%addBlock(2,b2)
Would be great if you could try to find a maximally reduced test for this case,
too. That would definitely help a lot.
In the meantime, I will start looking at the case in comment 1 ...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (2 preceding siblings ...)
2012-10-02 22:36 ` janus at gcc dot gnu.org
@ 2012-10-02 22:46 ` janus at gcc dot gnu.org
2012-10-02 23:44 ` janus at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-02 22:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #4 from janus at gcc dot gnu.org 2012-10-02 22:45:31 UTC ---
(In reply to comment #1)
>
> allocate(d%L(2)%B,source=b1)
>
The code generated for this line has two parts: The allocation and the copying
from the source. While the first part looks fine, it seems there is a problem
in the second. -fdump-tree-original shows:
{
struct block D.1890;
struct list[2] * D.1889;
D.1889 = &d.l;
D.1890 = b1;
{
integer(kind=8) S.0;
S.0 = 1;
while (1)
{
if (S.0 > 2) goto L.1;
__vtab_bug_Block._copy (&D.1890, (*D.1889)[S.0 + -1].b._data);
S.0 = S.0 + 1;
}
L.1:;
}
}
In principle only one element of the array 'd.l' should be copied. However, it
seems like the while loop does a copy for each element!
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (3 preceding siblings ...)
2012-10-02 22:46 ` janus at gcc dot gnu.org
@ 2012-10-02 23:44 ` janus at gcc dot gnu.org
2012-10-03 10:38 ` janus at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-02 23:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #5 from janus at gcc dot gnu.org 2012-10-02 23:43:42 UTC ---
The following patch seems to cure the test case in comment 1, as well as both
variants in comment 0:
Index: gcc/fortran/trans-stmt.c
===================================================================
--- gcc/fortran/trans-stmt.c (revision 192004)
+++ gcc/fortran/trans-stmt.c (working copy)
@@ -5145,7 +5145,9 @@ gfc_trans_allocate (gfc_code * code)
dataref = actual->next->expr->ref;
/* Make sure we go up through the reference chain to
the _data reference, where the arrayspec is found. */
- while (dataref->next && dataref->next->type != REF_ARRAY)
+ while (!(dataref->type == REF_COMPONENT
+ && strcmp (dataref->u.c.component->name, "_data") == 0)
+ && dataref->next)
dataref = dataref->next;
if (dataref->u.c.component->as)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (4 preceding siblings ...)
2012-10-02 23:44 ` janus at gcc dot gnu.org
@ 2012-10-03 10:38 ` janus at gcc dot gnu.org
2012-10-03 16:09 ` [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE janus at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-03 10:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #6 from janus at gcc dot gnu.org 2012-10-03 10:38:22 UTC ---
(In reply to comment #5)
> The following patch seems to cure the test case in comment 1, as well as both
> variants in comment 0:
... and regtests cleanly!
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (5 preceding siblings ...)
2012-10-03 10:38 ` janus at gcc dot gnu.org
@ 2012-10-03 16:09 ` janus at gcc dot gnu.org
2012-10-08 16:23 ` sfilippone at uniroma2 dot it
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-03 16:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[OOP] allocation of |[4.7/4.8 Regression] [OOP]
|extended types with |wrong code in polymorphic
|polymorphic allocatable |allocation with SOURCE
|members |
--- Comment #7 from janus at gcc dot gnu.org 2012-10-03 16:09:03 UTC ---
This even seems to be a regression: The test case in comment 1 runs without
error when compiled with gfortran 4.6 (and also the dump looks ok).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (6 preceding siblings ...)
2012-10-03 16:09 ` [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE janus at gcc dot gnu.org
@ 2012-10-08 16:23 ` sfilippone at uniroma2 dot it
2012-10-09 10:00 ` sfilippone at uniroma2 dot it
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-08 16:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
Salvatore Filippone <sfilippone at uniroma2 dot it> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sfilippone at uniroma2 dot
| |it
--- Comment #8 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-08 16:22:42 UTC ---
Hello,
I have a different problem that is definitely related to this area, but may or
may not be the same.
I have (as usual :) a complex nesting of polymorphic derived types, and I have
a need to handle reallocation and re-population of a vector of such containers.
The type hierarchy is something like this
type mld_d_base_solver_type
end type
type mld_d_base_smoother_type
class(mld_d_base_solver_type), allocatable :: sv
end
type mld_d_onelev_type
class(mld_d_base_smoother_type), allocatable :: sm
end type
type, extends(psb_dprec_type) :: mld_dprec_type
type(mld_d_onelev_type), allocatable :: precv(:)
end type
Consider the following snippet of code:
--------------------
deallocate(p%precv,stat=info)
if (info == 0) allocate(p%precv(newsz),stat=info)
if (info /= 0) then
info = -1
return
end if
do i=1, newsz
if (info == 0) then
if (i ==1) then
allocate(p%precv(i)%sm,source=base_sm,stat=info)
else if (i < newsz) then
allocate(p%precv(i)%sm,source=med_sm,stat=info)
else
allocate(p%precv(i)%sm,source=coarse_sm,stat=info)
end if
end if
if (info /= 0) then
info = -1
return
end if
write(0,*) 'Copy back at level',i
do k=1,i
write(0,*) ' level',k
call p%precv(k)%sm%sv%descr(info,iout=0)
if (info /= 0) return
end do
end do
------------------------------------------------
You would expect the allocate with source at I=4 to leave untouched the
elements of p%precv(1:3), and yet this is the output I get with 4.7.2:
------------------------------------------------
Copy back at level 1
level 1
TLU: test a new solver kind
Copy back at level 2
level 1
TLU: test a new solver kind
level 2
TLU: test a new solver kind
Copy back at level 3
level 1
TLU: test a new solver kind
level 2
TLU: test a new solver kind
level 3
TLU: test a new solver kind
Copy back at level 4
level 1
Incomplete factorization solver: ILU(n)
Fill level: 0
level 2
Incomplete factorization solver: ILU(n)
Fill level: 0
level 3
Incomplete factorization solver: ILU(n)
Fill level: 0
level 4
Incomplete factorization solver: ILU(n)
Fill level: 0
Intermediate at level 1
Incomplete factorization solver: ILU(n)
Fill level: 0
-----------------------------------------------------------------
This clearly does not make sense.
I can send Janus the full code to reproduce the error.
Does it seem related?
Thanks
Salvatore
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (7 preceding siblings ...)
2012-10-08 16:23 ` sfilippone at uniroma2 dot it
@ 2012-10-09 10:00 ` sfilippone at uniroma2 dot it
2012-10-10 11:49 ` janus at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: sfilippone at uniroma2 dot it @ 2012-10-09 10:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #9 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2012-10-09 09:59:28 UTC ---
Just opened 54874. May or may not be a duplicate of this one.....
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (8 preceding siblings ...)
2012-10-09 10:00 ` sfilippone at uniroma2 dot it
@ 2012-10-10 11:49 ` janus at gcc dot gnu.org
2012-10-11 17:53 ` janus at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ 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=54784
--- Comment #10 from janus at gcc dot gnu.org 2012-10-10 11:49:02 UTC ---
*** Bug 54874 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (9 preceding siblings ...)
2012-10-10 11:49 ` janus at gcc dot gnu.org
@ 2012-10-11 17:53 ` janus at gcc dot gnu.org
2012-10-11 17:58 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-11 17:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #11 from janus at gcc dot gnu.org 2012-10-11 17:52:44 UTC ---
Author: janus
Date: Thu Oct 11 17:52:36 2012
New Revision: 192374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192374
Log:
2012-10-11 Janus Weil <janus@gcc.gnu.org>
PR fortran/54784
* trans-stmt.c (gfc_trans_allocate): Correctly determine the reference
to the _data component for polymorphic allocation with SOURCE.
2012-10-11 Janus Weil <janus@gcc.gnu.org>
PR fortran/54784
* gfortran.dg/class_allocate_13.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_13.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (10 preceding siblings ...)
2012-10-11 17:53 ` janus at gcc dot gnu.org
@ 2012-10-11 17:58 ` janus at gcc dot gnu.org
2012-10-14 22:16 ` janus at gcc dot gnu.org
2012-10-14 22:27 ` janus at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-11 17:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #12 from janus at gcc dot gnu.org 2012-10-11 17:58:19 UTC ---
r192374 fixes the problem on trunk. Will commit to the 4.7 branch soon.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (11 preceding siblings ...)
2012-10-11 17:58 ` janus at gcc dot gnu.org
@ 2012-10-14 22:16 ` janus at gcc dot gnu.org
2012-10-14 22:27 ` janus at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-14 22:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #13 from janus at gcc dot gnu.org 2012-10-14 22:16:29 UTC ---
Author: janus
Date: Sun Oct 14 22:16:24 2012
New Revision: 192442
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192442
Log:
2012-10-14 Janus Weil <janus@gcc.gnu.org>
PR fortran/54784
* trans-stmt.c (gfc_trans_allocate): Correctly determine the reference
to the _data component for polymorphic allocation with SOURCE.
2012-10-14 Janus Weil <janus@gcc.gnu.org>
PR fortran/54784
* gfortran.dg/class_allocate_13.f90: New.
Added:
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/class_allocate_13.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/trans-stmt.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
2012-10-02 20:07 [Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members jkozdon at gmail dot com
` (12 preceding siblings ...)
2012-10-14 22:16 ` janus at gcc dot gnu.org
@ 2012-10-14 22:27 ` janus at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: janus at gcc dot gnu.org @ 2012-10-14 22:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #14 from janus at gcc dot gnu.org 2012-10-14 22:27:12 UTC ---
Fixed for the upcoming releases 4.8.0 and 4.7.3. Closing.
Thanks again for the report!
^ permalink raw reply [flat|nested] 15+ messages in thread