bug realloc-lhs

[Paul Richard Thomas]

Dear All,

This is indeed a bug.  A reduced and tidied testcase that exhibits the
problem is:
program test
  implicit none
  type po
    real(8), dimension(:), allocatable :: p
  end type
  type(po) :: p1
  allocate(p1%p(1))
  p1=toto(p1)
  print *, p1%p
contains
  function toto(dd) result(y)
    type(po) ::dd,y
    deallocate(dd%p)
  end function toto
end program test

The call to toto gives the following code:
          D.1880 = p1;
          p1 = toto (&p1);
          if (D.1880.p.data != 0B)
            {
              __builtin_free ((void *) D.1880.p.data);
            }
          D.1880.p.data = 0B;

Thus, if dd is deallocated within toto, without reassigning something
to dd%p, the address of p.data is retained by D.1880 and so it is
doubly freed.  This can be tested by adding an assignment to dd%p,
after the deallocation, whereupon everything works as it should.  For
example,
program test
  implicit none
  type po
    real(8), dimension(:), allocatable :: p
  end type
  type(po) :: p1
  allocate(p1%p(1))
  p1=toto(p1)
  print *, p1%p
contains
  function toto(dd) result(y)
    type(po) ::dd,y
    deallocate(dd%p)
    dd%p = [1d0, 2d0]
    y = dd
  end function toto
end program test

produces:
[pault@localhost tmp]# /irun/bin/gfortran -static -fdump-tree-original
testpointer.f90
[pault@localhost tmp]# ./a.out
   1.0000000000000000        2.0000000000000000

Could you please enter a bug report?  A check is needed to prevent
deallocation and nullification of D.1880.p.data if it is equal to
p1.p.data, after the function call.

Thanks

Paul

On Wed, Mar 28, 2012 at 9:26 PM, patnel97269-gfortran@yahoo.fr
<patnel97269-gfortran@yahoo.fr> wrote:
> The function have no side effect, and the user produces this function especiallly for the case.  Nothing prevent the user from deallocating an array of the type inside the function.
> And the standard said that if the array is no more of the same shape,size or not allocated, then it should be allocated to match the return of the function.
> So yes i blame the compiler not to verify whether the pointer is valid or not before reallocating.
>
> And by the way this code works perfectly as expected with the intel compiler.
>
> Patrice
>
>
> ----- Mail original -----
> De : Steve Kargl <sgk@troutmask.apl.washington.edu>
> À : "patnel97269-gfortran@yahoo.fr" <patnel97269-gfortran@yahoo.fr>
> Cc : Paul Richard Thomas <paul.richard.thomas@gmail.com>; "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
> Envoyé le : Mercredi 28 mars 2012 12h49
> Objet : Re: Re : bug realloc-lhs
>
> I think it is a not-so-special case of a user writing a
> function with a side-effect, and then blaming the compiler
> for not recognizing that the user has pulled the rug
> from under it.
>
> --
> steve
>
>
> On Wed, Mar 28, 2012 at 05:23:15PM +0100, patnel97269-gfortran@yahoo.fr wrote:
>> I'm using gfortran 4.6.3 (not 4.7 yet) on a linux 64bit. ?I think this is a special case in which the realloc-lhs doesn't work as expected. I can't tell if it's a regression or not. Patrice
>>
>>
>> ----- Mail original -----
>> De : Paul Richard Thomas <paul.richard.thomas@gmail.com>
>> À : Steve Kargl <sgk@troutmask.apl.washington.edu>
>> Cc : "patnel97269-gfortran@yahoo.fr" <patnel97269-gfortran@yahoo.fr>; "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
>> Envoyé le : Mercredi 28 mars 2012 8h58
>> Objet : Re: bug realloc-lhs
>>
>> You do not tell us which version of gfortran you are using nor on what
>> system you are running.  Without this information, we can say nothing
>> useful.
>>
>> Paul
>>
>> On Tue, Mar 27, 2012 at 9:20 PM, Steve Kargl
>> <sgk@troutmask.apl.washington.edu> wrote:
>> > On Tue, Mar 27, 2012 at 08:06:09PM +0100, patnel97269-gfortran@yahoo.fr wrote:
>> >> Hi all,
>> >>
>> >> I want to report a bug concerning the realloc-lhs, in case of a type containing a allocatable array.
>> >> For just an allocatable array it's ok ,everything works fine, when i deallocate the array in a function it's reallocated with the "=" statement;
>> >> But for a type i got a double free corruption, so i think there a test here to know if the array in the type is allocated or not. Note that if i don't allocate the array in the type at the beginning without deallocating it works.
>> >>
>> >> Here is the code .
>> >
>> > Looks like the type of problem, one might expect from
>> > invoking a function with side-effect.
>> >
>> > --
>> > Steve
>>
>>
>>
>> --
>> The knack of flying is learning how to throw yourself at the ground and miss.
>>        --Hitchhikers Guide to the Galaxy
>>
>
> --
> Steve
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy