Incorrect behavior when assigning pointer

[Tobias Burnus]

Hi Andrew,

Andrew Benson:
> That's very intersting. I also don't understand the issue reported by 
> Cray ftn. "cBh" is not a pointer, so the only relevant condition in 
> the Cray ftn error message is "an unallocated array", but the 
> preceding if statement is checking that the array is allocated.

Usually, the compiler keep track of this – either by storing the base 
address of the allocated memory somewhere or by specially marking the 
variable (in the array descriptor) as being allocated. The idea is to 
give an error when one does the following. I think the standard mandates 
that a compiler is able to diagnose it. (gfortran currently does not.)

   pointer :: ptr
   target :: tgt
   ptr => tgt
   deallocate(ptr, stat=istat)
   if (istat == 0) error stop "The Fortran should have detected this"
   stop "Ok"
   end

Those checks should be rather robust, thus, the odds are high that the 
memory is corrupted. (Either the program has a bug or the compiler 
generates code which does so.)

> With some modifications to the code, I can create the same problem 
> without the DEALLOCATE line being included (code appended below). 
> Could you check what Cray ftn says in this case? 

As there is no DEALLOCATE, no run-time error occurs; additionally, you 
get your "2 = 2" in the last line. On the other hand, with ifort version 
12.1.6 your new program crashes with a segmentation fault. With -check 
all, it states:
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable 
variable CBH when it is not allocated

That's the last line of:

  function bhGet(self,autoCreate)
...
     select type (self)
     type is (tn)
        allocate(self%cBh(1),source=defaultBhC)
        self%cBh(1)%hostNode => self

At a glance, it looks as if their allocate has a bug.

> Thanks - I've corrected this in my code. For me, gfortran accepts both with
> and without the TARGET added, but in both cases still results in the wrong
> output.

As written, that gfortran accepts it without TARGET is a known bug. 
While you might run into problems with -O2/-O3/-Ofast, it was kind of 
expected that it doesn't affect -O0 compilation - though, it sometimes does.

> I also checked that valgrind doesn't report any issues, for what it's worth.

Ditto here: No warning and no leaked memory with gfortran.related issues.


I think it would be useful to find out whether gfortran has a bug, but 
your program it too convoluted to really see it. (Maybe one does, if one 
prints out your program and manually runs it with pen and paper.)

Tobias