[Bug fortran/43412] [OOP] BT_CLASS does not does not set array spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43412 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/43412] [OOP] BT_CLASS does not does not set array spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43412 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mikael at gcc dot gnu.org Known to work||4.7.4, 4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #3 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) while the test in comment #1 compiles without error. AFAIU this is the expected behavior, isn't it? It seems so. Closing.
[Bug fortran/43412] [OOP] BT_CLASS does not does not set array spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43412 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-28 23:47:42 UTC --- With trunk at revision 183668, compiling the test in comment #0 gives the error [macbook] f90/bug% gfc pr43412.f90 pr43412.f90:8.27: class(t), pointer :: y(*) ! invalid 1 Error: Assumed size polymorphic objects or components, such as that at (1), have not yet been implemented while the test in comment #1 compiles without error. AFAIU this is the expected behavior, isn't it?
[Bug fortran/43412] [OOP] BT_CLASS does not does not set array spec
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-28 08:57 --- Created an attachment (id=20505) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20505action=view) coarray_13.f90 test case Depending on this fix are constraint checking for coarrays, cf. attached test case. * * * Current result: allocate(t :: z[*]) 1 Error: Unexpected coarray designator at (1) Reason: gfc_match_array_ref's corank argument is 0. And the argument is sym-as or component-as (cf. primary). * * * class(t), allocatable :: z[:] ! Fails due to sym-attr.allocatable 1 Error: Variable 'z' at (1) is a coarray or has a coarray component and is not ALLOCATABLE, SAVE nor a dummy argument See check in resolve.c's resolve_symbol. And I do not really want to add tons of special cases for BT_CLASS; the check is already quite long: /* F2008, C526. The function-result case was handled above. */ if (((sym-ts.type == BT_DERIVED sym-ts.u.derived-attr.coarray_comp) || sym-attr.codimension) !(sym-attr.allocatable || sym-attr.dummy || sym-attr.save || sym-ns-proc_name-attr.flavor == FL_MODULE || sym-ns-proc_name-attr.is_main_program || sym-attr.function || sym-attr.result || sym-attr.use_assoc)) * * * Possibly related: PR 41539 (also as = NULL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43412