Bug 41937 - [OOP] Error in allocating derived type allocatable components
Summary: [OOP] Error in allocating derived type allocatable components
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2009-11-04 12:38 UTC by Juergen Reuter
Modified: 2009-11-04 19:46 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-11-04 16:33:35


Attachments
sample code for the bug case (219 bytes, application/octet-stream)
2009-11-04 12:39 UTC, Juergen Reuter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Juergen Reuter 2009-11-04 12:38:05 UTC
When trying to compile the sample file, gfortran (I'm referring to the revision
r153847) chokes over allocating an allocatable array whose length depends on an integer derived type in the same abstract type.
gfortran -c cuba_types_bug.f03
cuba_types_bug.f03:16.28:

      allocate(this%integral(this%dim_f))
                            1
Error: 'this' must not appear in the array specification at (1) in the same ALLOCATE statement where it is itself allocated

I think the code is OK according to the F2003 specification.

******
The test code is:
module cuba_types_module
  implicit none

  type, abstract :: cuba_abstract_type
     private
     integer :: dim_f = 1
     real, dimension(:), allocatable :: integral
   contains
     procedure :: alloc_dim_f => cuba_abstract_alloc_dim_f
  end type cuba_abstract_type

  contains

    subroutine cuba_abstract_alloc_dim_f(this)
      class(cuba_abstract_type) :: this
      allocate(this%integral(this%dim_f))
    end subroutine cuba_abstract_alloc_dim_f

end module cuba_types_module
Comment 1 Juergen Reuter 2009-11-04 12:39:46 UTC
Created attachment 18963 [details]
sample code for the bug case
Comment 2 Tobias Burnus 2009-11-04 14:33:01 UTC
Confirmed. The following - untested - should fix it. I am not sure, when I have time to submit it. Janus, if you want to do the honour, go ahead.

Index: resolve.c
===================================================================
--- resolve.c   (revision 153896)
+++ resolve.c   (working copy)
@@ -6198,7 +6198,8 @@ check_symbols:
          sym = a->expr->symtree->n.sym;

          /* TODO - check derived type components.  */
-         if (sym->ts.type == BT_DERIVED)
+         if (sym->ts.type == BT_DERIVED
+             || sym->ts.type == BT_CLASS)
            continue;

          if ((ar->start[i] != NULL
Comment 3 janus 2009-11-04 16:33:35 UTC
(In reply to comment #2)
> Janus, if you want to do the honour, go ahead.

Yes, I can do it.
Comment 4 janus 2009-11-04 19:41:22 UTC
Subject: Bug 41937

Author: janus
Date: Wed Nov  4 19:41:07 2009
New Revision: 153911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153911
Log:
2009-11-04  Tobias Burnus <burnus@gcc.gnu.org>
	    Janus Weil  <janus@gcc.gnu.org>

	PR fortran/41556
	PR fortran/41937
	* interface.c (gfc_check_operator_interface): Handle CLASS arguments.
	* resolve.c (resolve_allocate_expr): Handle allocatable components of
	CLASS variables.


2009-11-04  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/41556
	PR fortran/41937
	* gfortran.dg/class_11.f03: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_11.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

Comment 5 janus 2009-11-04 19:46:06 UTC
Fixed with r153911. Closing.