http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46182
Summary: Run time check for invalid use of unallocated
allocatable variables
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
While the following code
type b
integer, allocatable :: i(:)
end type b
type(b), allocatable :: a(:)
!allocate(a(10))
print *, allocated(a)!, allocated(a(1)%i)
!deallocate(a)
end
seems to be a valid f2003 code and gives 'F' at run time, replacing
print *, allocated(a)!, allocated(a(1)%i)
with
print *, allocated(a), allocated(a(1)%i)
gives a "Segmentation fault" at run time (it gives 'T F' if the
allocate/deallocate lines are uncommented).
When asked on IRC about this kind of inquiry of a component of an unallocated
derived type, Tobias Burnus answered immediately that such a use is invalid,
pointing to
2.4.9 Allocatable variables
...
2 An unallocated allocatable variable shall not be referenced or defi ned.
...
Then he made the comment that (obviously) this restriction does not apply for
13.7.11 ALLOCATED (ARRAY) or ALLOCATED (SCALAR)
1 Description. Query allocation status.
2 Class. Inquiry function.
3 Arguments.
ARRAY shall be an allocatable array.
SCALAR shall be an allocatable scalar.
4 Result Characteristics. Default logical scalar.
5 Result Value. The result has the value true if the argument (ARRAY or SCALAR)
is allocated and has the
value false if the argument is unallocated.
but that 'a(1)%i' is not an array but an invalid expression per 2.4.9 that
cannot be a valid argument of allocated. Note that my original problem came
from scalar allocatable and that the above was less obvious for 'a%i'.
It would be nice to have a run time check for such invalid use of unallocated
allocatable variables (such as -fcheck=use_unalloc).
