Standard conformance question

[Salvatore Filippone <salvatore dot filippone at uniroma2 dot it>]

Hi there, 
While chasing a bug with the allocatable components TR, I tried to get
an independent compilation of a piece of code with the XLF compiler. I
had reduced a test case into a self contained file, and in so doing I
produced something that the XLF compiler spewed out like this:

bash-2.05b$ xlf95 -c test_ab9.f90
"test_ab9.f90", line 1.21: 1513-213 (S) A derived-type object that
appears as a dummy argument in an external procedure definition must be
of a sequence type or a type with the BIND(C) attribute, unless it is of
a type that is use-associated.
** test_ab9   === End of Compilation 1 ===
1501-511  Compilation failed for file test_ab9.f90.


The current version of gfortran (snapshot 20060923 + TR15581 patch)
doesn't balk at it:
[sfilippo@localhost ALLOCATABLE]$ gfortran -v 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2-20060923/configure --prefix=/usr/local/gcc42
Thread model: posix
gcc version 4.2.0 20060923 (experimental)
[sfilippo@localhost ALLOCATABLE]$ gfortran -c test_ab9.f90 
[sfilippo@localhost ALLOCATABLE]$ 


I guess the question is: does the standard require such an error to be
diagnosed? Is it dependent on F2003 features being enabled? 
I understand my code might be wrong (even though that would be an
artifact of trying to produce a self-contained test case), but there is
a substantial difference in behaviour.
Any standard guru out there cares to comment? 

Thanks

Salvatore

---------------------- test_ab9.f90  -------------
subroutine test_ab9(p)

  implicit none



  type bp_type
     integer, pointer  :: m_d(:)
  end type bp_type

  type p_type
    type(bp_type), pointer  :: bpv(:) 
    integer                    :: prc, bprc
  end type p_type

  type(p_type)    :: p

  type(bp_type), pointer   :: bpv(:)
  integer                      :: isz, err



  write(0,*) associated(p%bpv)
  
end subroutine test_ab9