[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Sep 3 06:41:37 2014 New Revision: 214843 URL: https://gcc.gnu.org/viewcvs?rev=214843root=gccview=rev Log: Missed that file in r213079 of 2014-07-26 2014-09-03 Tobias Burnus bur...@net-b.de PR fortran/61881 PR fortran/61888 PR fortran/57305 * gfortran.dg/sizeof_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/sizeof_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT this PR has been fixed by r213079.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #13) AFAICT this PR has been fixed by r213079. Yes. I have implemented it to return - as in comment 6's option (c): It returns the size of the dynamic type. However, I missed to do what comment 9 mentioned: Updating the documentation. I will do this as follow-up patch. (In reply to janus from comment #11) TODO: A proper treatment of array arguments seems to be missing for both SIZEOF and STORAGE_SIZE. Seems to work okay: It returns the element-size times array size. For a noncontiguous array, SIZEOF is not really defined – and for STORAGE_SIZE should simply return the size in bytes, which should be fine as well. Does anyone see a problem with the current implementation?
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Sat Jul 26 17:56:39 2014 New Revision: 213085 URL: https://gcc.gnu.org/viewcvs?rev=213085root=gccview=rev Log: Follow up to r213079. 2014-07-26 Tobias Burnus bur...@net-b.de PR fortran/61881 PR fortran/61888 PR fortran/57305 * intrinsic.texi (SIZEOF): Document changed behavior for polymorphic arrays. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/gcc/testsuite/ChangeLog
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org --- Close as FIXED in the GCC 5 trunk (alias 4.10).
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any reason why the patch in comment 7 has not been applied? I have it in my working tree since a while without any associated problem.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #10) Any reason why the patch in comment 7 has not been applied? It was posted at http://gcc.gnu.org/ml/fortran/2013-08/msg00068.html some time ago, but did not directly get an ok and was apparently forgotten about again. TODO: A proper treatment of array arguments seems to be missing for both SIZEOF and STORAGE_SIZE. Question is whether the patch should be applied now and the array treatment added later, or if it should happen in one go.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- TODO: A proper treatment of array arguments seems to be missing for both SIZEOF and STORAGE_SIZE. ??? besides if (sizeof(b)/= 24) call abort() if (storage_size(b) /= 64) call abort() Question is whether the patch should be applied now and the array treatment added later, or if it should happen in one go. Unless the patch remove the ICE by silent wrong codes, I'ld say incremental fix is not bad.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||janus at gcc dot gnu.org Summary|ICE with warnings and |[OOP] ICE when calling |unlimited polymorphic |SIZEOF on an unlimited ||polymorphic variable --- Comment #5 from janus at gcc dot gnu.org --- The ICE on comment 1 seems to be due to the SIZEOF call. Reduced test case: subroutine add_element_poly(e) class(*) :: e print *, sizeof(e) end subroutine Fails with 4.8 and current trunk.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) The ICE on comment 1 seems to be due to the SIZEOF call. ... which is basically because SIZEOF is supposed to return the size of the declared type, and a CLASS(*) doesn't really have a declared type, cf. also http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html Of course SIZEOF is a GNU extension, so we are free to define its behavior in any way we please. I don't remember why it was chosen to take the size of the declared type back in the day. When it was implemented for polymorphics, CLASS(*) was not yet available in gfortran. One way out: You could use STORAGE_SIZE, which is standard F08 and returns the size of the *dynamic* type. Also it seems to work well with CLASS(*). In any case the ICE should be fixed by one of the following approaches: 1) reject SIZEOF on CLASS(*) 2) make it return 0 for CLASS(*) 3) make it return the size of the dynamic type Option #3 is probably what you were expecting, right? I don't see any reason for not going this route, except that changing behavior is bad in general. But if it fixes an ICE, I guess it's not that bad after all ...
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #7 from janus at gcc dot gnu.org --- Created attachment 30682 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30682action=edit patch Here is a preliminary patch to make SIZEOF return the size of the dynamic type for polymorphic variables, which at the same time fixes the ICE on CLASS(*) variables.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) Here is a preliminary patch to make SIZEOF return the size of the dynamic type for polymorphic variables, which at the same time fixes the ICE on CLASS(*) variables. Of course this fails on storage_size_1, which expects the old behavior for CLASS variables, but otherwise it regtests cleany. Index: gcc/testsuite/gfortran.dg/storage_size_1.f08 === --- gcc/testsuite/gfortran.dg/storage_size_1.f08(revision 201896) +++ gcc/testsuite/gfortran.dg/storage_size_1.f08(working copy) @@ -25,7 +25,7 @@ if (storage_size(a) /= 64) call abort() if (sizeof(b)/= 24) call abort() if (storage_size(b) /= 64) call abort() -if (sizeof(cp) /= 8) call abort() +if (sizeof(cp) /= 12) call abort() if (storage_size(cp) /= 96) call abort() end
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #9 from janus at gcc dot gnu.org ---
And of course the changed behavior should be reflected in the documentation:
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi(revision 201896)
+++ gcc/fortran/intrinsic.texi(working copy)
@@ -11546,7 +11546,7 @@ number of bytes occupied by the argument. If the
to is returned. If the argument is of a derived type with @code{POINTER}
or @code{ALLOCATABLE} components, the return value does not account for
the sizes of the data pointed to by these components. If the argument is
-polymorphic, the size according to the declared type is returned. The argument
+polymorphic, the size according to the dynamic type is returned. The argument
may not be a procedure or procedure pointer.
@item @emph{Example}:
