[Bug fortran/46017] New: Reject ALLOCATE(a, a%b) as "a%b" depends on the allocation status of "a"

[Bug fortran/46017] New: Reject ALLOCATE(a, a%b) as "a%b" depends on the allocation status of "a"

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017

           Summary: Reject  ALLOCATE(a, a%b) as  "a%b" depends on the
                    allocation status of "a"
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Follow up to PR 42647 comment 11

  allocate(a1, a1%b1, a1%b1%c1)

is invalid as it violates:

"An allocate-object [...] shall not depend [...] on the [...] allocation status
[...] of any allocate-object in the same ALLOCATE statement."

(F2008, "6.7.1 ALLOCATE statement" first paragraph after C644.)


The solution is to write three independent ALLOCATE statements. I think this
particular case could be compile-time detectable.

Cf. also http://gcc.gnu.org/ml/fortran/2010-10/msg00159.html (contains quote
from the F2003 handbook.)

Full test case: PR 42647 comment 10

[Bug fortran/46017] Reject ALLOCATE(a, a%b) as "a%b" depends on the allocation status of "a"

[dfranke at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017

Daniel Franke <dfranke at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.29 02:57:44
                 CC|                            |dfranke at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-29 02:57:44 UTC ---
Small testcase with additional twist: double allocation of 'tt' is not reported
either:

  TYPE :: t
    INTEGER, ALLOCATABLE :: a(:)
  END TYPE

  TYPE(t), ALLOCATABLE :: tt
  ALLOCATE (tt, tt, tt%a(3))
END

[Bug fortran/46017] Reject ALLOCATE(a, a%b) as "a%b" depends on the allocation status of "a"

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |tkoenig at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |tkoenig at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-01-01 22:26:13 UTC ---
I have a patch.

[Bug fortran/46017] Reject ALLOCATE(a, a%b) as "a%b" depends on the allocation status of "a"

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-01-05 10:03:18 UTC ---
Author: tkoenig
Date: Wed Jan  5 10:03:15 2011
New Revision: 168506

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168506
Log:
2011-01-05  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/46017
    * resolve.c (resolve_allocate_deallocate): Follow references to
    check for duplicate occurence of allocation/deallocation objects.

2011-01-05  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/46017
    * gfortran.dg/allocate_error_2.f90:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_error_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/46017] Reject ALLOCATE(a, a%b) as "a%b" depends on the allocation status of "a"

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-01-08 22:05:20 UTC ---
Fixed on trunk, closing.