[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #7 from janus at gcc dot gnu.org 2011-01-05 09:05:48 UTC --- Author: janus Date: Wed Jan 5 09:05:44 2011 New Revision: 168505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168505 Log: 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47024 * trans-decl.c (gfc_trans_deferred_vars): Initialize the _vpr component of polymorphic allocatables according to their declared type. 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47024 * gfortran.dg/storage_size_3.f08: New. Added: trunk/gcc/testsuite/gfortran.dg/storage_size_3.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from janus at gcc dot gnu.org 2011-01-05 09:17:25 UTC --- Fixed with r168505. Closing.
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.04 13:39:10 Ever Confirmed|0 |1 --- Comment #4 from janus at gcc dot gnu.org 2011-01-04 13:39:10 UTC --- (In reply to comment #2) However, if A is unallocated, it does not have a dynamic type! According to Bill Long's interpretation at http://j3-fortran.org/pipermail/j3/2010-December/004094.html the dynamic type of an unallocated variable is it's dynamic type.
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024
--- Comment #5 from janus at gcc dot gnu.org 2011-01-04 13:49:27 UTC ---
The dump for the test case in comment #0 currently looks like this [excerpt]:
y._data = 0B;
{
[...]
_gfortran_st_write (dt_parm.0);
{
integer(kind=4) D.1548;
D.1548 = (y._vptr-_size * 8) / 8;
_gfortran_transfer_integer_write (dt_parm.0, D.1548, 4);
}
_gfortran_st_write_done (dt_parm.0);
}
Since y._vptr is initially undefined, we get an ICE. The solution would be to
initialize the _vptr component of all polymorphic allocatables to the declared
type.
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 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 #6 from janus at gcc dot gnu.org 2011-01-04 18:58:30 UTC --- Mine. Have a patch.
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 09:47:11 UTC --- IR 10-171 (http://j3-fortran.org/doc/year/10/10-171.txt) adds the text in the bracket (which does not apply here): If it [is unlimited polymorphic or] has any deferred type parameters it shall not be ... * * * I have now asked at J3: http://j3-fortran.org/pipermail/j3/2010-December/004090.html
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #2 from janus at gcc dot gnu.org 2010-12-20 15:16:44 UTC --- (In reply to comment #0) STORAGE_SIZE does not work for unallocated polymorphic types. However, the Fortran 2008 standard allows them: Ashall be a scalar or array of any type. If it is polymorphic it shall not be an undefined pointer. If it has any deferred type parameters it shall not be an unallocated allocatable variable or a disassociated or undefined pointer. (F2008, 13.7.160) I don't really understand this. Why should one allow it for unallocated allocatables, but not for undefined pointers? Also, it's not exactly clear to me which value to expect for such a case. From the standard's description of STORAGE_SIZE: The result value is the size expressed in bits for an element of an array that has the dynamic type and type parameters of A. However, if A is unallocated, it does not have a dynamic type!
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-20 16:47:56 UTC --- (In reply to comment #2) I don't really understand this. Why should one allow it for unallocated allocatables, but not for undefined pointers? Well, the situation for an unassociated pointer and for an unallocated allocatable is the same: You know that it does not have a dynamic type -- and you can check for this state via array.data == NULL or scalar == NULL. In case of an undefined pointer, you cannot. Thus, not allowing undefined pointers anywhere makes sense. The initially proposed wording was did not allow for notallocated allocatables/notassociated pointers (http://www.j3-fortran.org/doc/year/06/06-166.txt) but during the meeting 176 meeting the wording of 06-166 was changed (in two revisions, r1 and r2) to what we have today; cf. http://www.j3-fortran.org/doc/meeting/176/06-166r2.txt. Unfortunately, the new version does not clearly tell what the result value should be in that case. Possible choices would be: (a) storage size of the declared type or (b) zero or the size of the class container. If (b) is the correct answer, I do not see the reason for the additional restrictions for types with deferred type parameters and for unlimited polymorphic - one could simply return the same as for an unallocated polymorphic. Thus, I assume that (a) is meant, but I do not see how one can read this from the standard (as opposed to guessing it). Let's see what the J3 members think how it should be interpreted; I think ultimately an interpretation request is required.
