The following program produces an internal compiler error: program test_objects implicit none type, abstract :: shape end type type, extends(shape) :: rectangle real :: width, height end type class(shape), dimension(2) :: object object(1) = rectangle( 1.0, 2.0 ) end program test_objects There is no indication as to what is wrong with the program (as Janus, who reduced my original program to this minimal one, remarks: there are at least two)
Removing the last line ("object(1) = rectangle ..."), one gets: class(shape), dimension(2) :: object 1 Error: CLASS variable 'object' at (1) must be dummy, allocatable or pointer
Fixing up the CLASS declaration with the ALLOCATABLE attribute yields: class(shape), dimension(2), allocatable :: object 1 Error: Polymorphic array at (1) not yet supported
Hi Janus, shouldn't that read: class(shape), dimension(:), allocatable :: object ^ | no fixed dimension (the error message itself is welcome of course) Regards, Arjen On 2011-02-14 11:09, janus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47728 > > --- Comment #2 from janus at gcc dot gnu.org 2011-02-14 10:09:15 UTC --- > Fixing up the CLASS declaration with the ALLOCATABLE attribute yields: > > class(shape), dimension(2), allocatable :: object > 1 > Error: Polymorphic array at (1) not yet supported > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
(In reply to comment #3) > shouldn't that read: > > class(shape), dimension(:), allocatable :: object > ^ > | no fixed dimension Yes, in principle it should. However, currently we boldly reject any kind of dimensionful class variable, before even getting to the point of checking the dimensions.
Hi Janus, understandable :). So, the ICE is occurring some point later then? Regards, Arjen On 2011-02-14 11:16, janus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47728 > > --- Comment #4 from janus at gcc dot gnu.org 2011-02-14 10:16:33 UTC --- > (In reply to comment #3) >> shouldn't that read: >> >> class(shape), dimension(:), allocatable :: object >> ^ >> | no fixed dimension > > Yes, in principle it should. However, currently we boldly reject any kind of > dimensionful class variable, before even getting to the point of checking the > dimensions. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
> Error: Polymorphic array at (1) not yet supported I wonder if this should not be a fatal error: if a feature is not implemented, it is likely to trigger several side effects (such as extra errors and ICEs, e.g., pr41600).
Hi Dominique, that does sound reasonable to me - but of course that means any other errors that could be reported after that will not show up until after the unimplemented feature has been removed. Regards, Arjen On 2011-02-14 11:23, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47728 > > --- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-14 10:23:49 UTC --- >> Error: Polymorphic array at (1) not yet supported > > I wonder if this should not be a fatal error: if a feature is not implemented, > it is likely to trigger several side effects (such as extra errors and ICEs, > e.g., pr41600). > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
Ok, here is a simple draft patch which gets rid of the ICE: Index: gcc/fortran/primary.c =================================================================== --- gcc/fortran/primary.c (revision 170124) +++ gcc/fortran/primary.c (working copy) @@ -1770,8 +1770,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl if ((equiv_flag && gfc_peek_ascii_char () == '(') || gfc_peek_ascii_char () == '[' || sym->attr.codimension - || (sym->attr.dimension && !sym->attr.proc_pointer - && !gfc_is_proc_ptr_comp (primary, NULL) + || (sym->attr.dimension && sym->ts.type != BT_CLASS + && !sym->attr.proc_pointer && !gfc_is_proc_ptr_comp (primary, NULL) && !(gfc_matching_procptr_assignment && sym->attr.flavor == FL_PROCEDURE)) || (sym->ts.type == BT_CLASS && sym->attr.class_ok If this survives the testsuite, I will commit it as obvious.
(In reply to comment #8) > If this survives the testsuite, I will commit it as obvious. Regtest successful. Will commit shortly.
Author: janus Date: Mon Feb 14 18:12:55 2011 New Revision: 170144 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170144 Log: 2011-02-14 Janus Weil <janus@gcc.gnu.org> PR fortran/47728 * class.c (gfc_build_class_symbol): Give a fatal error on polymorphic arrays. * primary.c (gfc_match_varspec): Avoid ICE for invalid class declaration. 2011-02-14 Janus Weil <janus@gcc.gnu.org> PR fortran/47728 * gfortran.dg/class_38.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_38.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
Fixed with r170144. I also followed Dominique's suggestion to reject polymorphic errors with a fatal error. Closing.
Hi Janus, great to hear that - that was quick work. Regards, Arjen On 2011-02-14 19:17, janus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47728 > > janus at gcc dot gnu.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|ASSIGNED |RESOLVED > Resolution| |FIXED > > --- Comment #11 from janus at gcc dot gnu.org 2011-02-14 18:17:28 UTC --- > Fixed with r170144. I also followed Dominique's suggestion to reject > polymorphic errors with a fatal error. > > Closing. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.