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 defined.
...

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).