[log in to unmask] said:
> Attempting to deallocate x after the second association gives a
> run-time error in ftn90, and a programmer might conceivably want to
> check for this form of association before carrying out deallocation. 

My Fortran95 favourite "Fortran 95 Handbook", Adams et al. says that a
pointer associated with an allocatable array must not be deallocated, but
the target may of cource be deallocated. If the pointer is associated
through an allocation it can of course be deallocated. The use of
deallocate in your situation should probably be:

deallocate(x,STAT=ierr)
if(ierr/=0)then
  write(*,*) "The deallocation was not performed..."
end if

Someone else can probably answer this with more confidence than I, but this
might be a wanted language design. You may want to design a language so
that it is only allowed to deallocate TARGETS. It will at least rule out
one source of use of un-allocated memory and dangling pointers.

In the current setting, handing a pointer of your data to a subroutine
allows for the routine to change the values, but it is guaranteed not to
remove your data storage from memory. 

It also makes the language a lot simpler since I guess to allow for
"indirected" deallocation (through pointers) would probably mean a much
more complex memory management needed. If a deallocation involved a
pointer, then the system would have to find all other pointers pointing to
the same target and modify their allocation/association status. Or store
the allocation status with the target itself and walking through the
pointer to find the allocation status of the target before it is possible
to. The current pointer treatment in Fortran does not need this (I think,
but I am an amateur in compiler/language design)

Modifying your test slightly as attached notified me that one of my available
compilers didn't do this correctly.

The correct output I belive should be:

[...]
 z(3)= 12.
 x(3)= 12.
 The deallocation was not performed...
 x associated after pointing at z.
 z is still allocated...

but from one I get:

[...]
 z(3)=   12.00000    
 x(3)=   12.00000    
 Deallocation was succesful...
 z is no longer allocated...

Which is still clever since deallocating x made z deallocated. But it 
contradicts the "Handbook" and then possibly also the standard it self?

Gurus out there - enlighten us....

/Nils