This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re : Re : Re : bug realloc-lhs
I've created the bug report ?:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52774
patrice
----- Mail original -----
De?: Paul Richard Thomas <paul.richard.thomas@gmail.com>
À?: "patnel97269-gfortran@yahoo.fr" <patnel97269-gfortran@yahoo.fr>
Cc?: Steve Kargl <sgk@troutmask.apl.washington.edu>; "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
Envoyé le : Mercredi 28 mars 2012 16h23
Objet?: Re: Re : Re : bug realloc-lhs
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