[Bug fortran/42112] New: overloaded function with allocatable result problem

[Bug fortran/42112] New: overloaded function with allocatable result problem

[mrestelli at gmail dot com]

The attached code produces an error at runtime, however it seems fine
to me. Notice that there is no error accessing the function with the
specific name "g", while there is an error when using the generic name
"gen_g".

gfortran --version
GNU Fortran (GCC) 4.5.0 20091105 (experimental)

gfortran ./abc.f90 -o abc

./abc 
At line 23 of file ./abc.f90
Fortran runtime error: Attempting to allocate already allocated array 'j'


module mod_m
 implicit none
 public :: f
 private

 interface gen_g
   module procedure g
 end interface

contains

 pure function f() result(i)
  integer :: i
  integer, allocatable :: loc_ar(:)
   allocate(loc_ar(1))
   loc_ar = gen_g() ! does not work
   !loc_ar = g() ! no problem here
   deallocate(loc_ar)
 end function f

 pure function g() result(j)
  integer, allocatable :: j(:)
   allocate( j(1) )
   j = 2
 end function g

end module mod_m

!--------------------------

program abc_main

 use mod_m, only: f
 implicit none
 integer :: p
  p = f()

end program abc_main


-- 
           Summary: overloaded function with allocatable result problem
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mrestelli at gmail dot com
  GCC host triplet: Linux 2.6.27-gentoo-r8 x86_64 AMD Turion(tm)
GCC target triplet: GNU Fortran (GCC) 4.5.0 20091105 (experimental)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

[Bug fortran/42112] overloaded function with allocatable result problem

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2009-11-19 23:55 -------
If you remove 

   allocate(loc_ar(1))

   deallocate(loc_ar)

in function f(), the code compiles and runs in either case.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sgk at troutmask dot apl dot
                   |                            |washington dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

[Bug fortran/42112] overloaded function with allocatable result problem

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #2 from sgk at troutmask dot apl dot washington dot edu  2009-11-20 00:20 -------
Subject: Re:  overloaded function with allocatable result problem

If the code is compiled with -fdump-tree-original one
immediately see the cause of the runtime error.  Eliminating
the common code in the dumps, I find this code

  pure function f() result(i)
    integer :: i
    integer, allocatable :: loc_ar(:)
    allocate(loc_ar(1))
    loc_ar = gen_g() ! does not work
    deallocate(loc_ar)
    i = 1
  end function f

generates

  f ()
  {
    g (&loc_ar);
  }

loc_ar has been allocated and the pointer to it is passed
to g() where is becomes associated with the result variable j.
You then try to allocate j, which is already allocated.


When you call g() directly in 

   pure function f() result(i)
    integer :: i
    integer, allocatable :: loc_ar(:)
    allocate(loc_ar(1))
    loc_ar = g() ! no problem here
    deallocate(loc_ar)
    i = 1
   end function f

the dump shows

  f ()
  {
    {
      integer(kind=8) D.1398;
      struct array1_integer(kind=4) atmp.1;
      integer(kind=8) D.1393;
      integer(kind=8) D.1392;
      integer(kind=8) D.1391;
      integer(kind=4)[0:] * restrict D.1390;

      D.1390 = (integer(kind=4)[0:] * restrict) loc_ar.data;
      D.1391 = loc_ar.offset;
      D.1392 = loc_ar.dim[0].lbound;
      D.1393 = loc_ar.dim[0].ubound;
      atmp.1.dtype = 265;
      atmp.1.data = 0B;
      atmp.1.offset = 0;
      g (&atmp.1);

g() is called with a unallocated temporary variable, so
your allocation in g() works.  The next several lines
copy atmp into loc_ar.

      D.1398 = NON_LVALUE_EXPR <D.1392>;
      {
      integer(kind=8) S.2;

      S.2 = 0;
      while (1)
        {
          if (atmp.1.dim[0].ubound - atmp.1.dim[0].lbound < S.2) goto L.2;
          (*D.1390)[(S.2 + D.1398) + D.1391]
                   = (*(integer(kind=4)[0:] * restrict) atmp.1.data)[S.2];
          S.2 = S.2 + 1;
        }
      L.2:;
    }

Here, the temporary variable is destroyed.

    {
      void * D.1397;

      D.1397 = (void *) atmp.1.data;
      if (D.1397 != 0B)
        {
          __builtin_free (D.1397);
        }
    }
  }
}

I need to go read the Fortran standard to determine the
semantics of a function returning an allocatable entity.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

[Bug fortran/42112] overloaded function with allocatable result problem

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2009-11-20 14:22 -------
  pure function f() result(i)
    integer :: i
    integer, allocatable :: loc_ar(:)
    allocate(loc_ar(1))
    loc_ar = gen_g() ! does not work

That looks OK if gen_g returns a size-1 array or a scalar - and with Fortran
2003 it should also be valid if the array has a different size (automatic
(re)allocation on assignment).

> generates
>
>  f ()
>  {
>    g (&loc_ar);
>  }
>
> loc_ar has been allocated and the pointer to it is passed
> to g() where is becomes associated with the result variable j.
> You then try to allocate j, which is already allocated.

That sounds completely wrong for Fortran 95 but also for 2003. There is
absolutely no valid reason to mess around with the LHS argument, i.e.
C_LOC(loc_ar(1)) should be the same before and after the assignment (unless in
F2003 if the array size of LHS/RHS does not match or if loc_ar was before not
allocated).

To me it sounds as if there is the problem that the attributes of the specific
function belonging to the generic function are not properly used.

That is: expr->symtree->n.sym->attr vs. expr->value.function.esym->attr. (Cf.
PR 41777 )


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2009-11-20 14:22:49
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

[Bug fortran/42112] overloaded function with allocatable result problem

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> 2010-11-21 11:41:13 UTC ---
(In reply to comment #0)

> Fortran runtime error: Attempting to allocate already allocated array 'j'
> 
....snip....

>    allocate(loc_ar(1))
>    loc_ar = gen_g() ! does not work
>    !loc_ar = g() ! no problem here
>    deallocate(loc_ar)
>  end function f
> 
>  pure function g() result(j)
>   integer, allocatable :: j(:)
>    allocate( j(1) )
>    j = 2
>  end function g

This looks correct to me, unless F2003 forces a reallocation in ALLOCATE, when
frealloc-lhs is in effect?

I will look tonight, unless somebody beats me to it.

If the first allocate is omitted, the code compiles..... but not with my patch.
****shucks***

Paul

[Bug fortran/42112] overloaded function with allocatable result problem

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> 2010-11-25 05:58:03 UTC ---
(In reply to comment #4)

> 
> This looks correct to me, unless F2003 forces a reallocation in ALLOCATE, when
> frealloc-lhs is in effect?

This is specifically not the case.  The standard says, unconditionally, that
the ALLOCATE statement generates and error with an already allocated array.

> 
> I will look tonight, unless somebody beats me to it.
> 
> If the first allocate is omitted, the code compiles..... but not with my patch.
> ****shucks***

I have fixed it for my rellocate on assign patch but a question remains that is
at the core of the original problem:

At trans-array.c:6958
  /* Dummy, use associated and result variables don't need anything special. 
*/
  if (sym->attr.dummy || sym->attr.use_assoc || sym->attr.result)
    {
      gfc_add_init_cleanup (block, gfc_finish_block (&init), NULL_TREE);
      return;
    }

ie. deallocation is not done on procedure entry for results.  I believe that
this is incorrect for gfortran's pass by reference handling of function
results.

Cheers

Paul

[Bug fortran/42112] overloaded function with allocatable result problem

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-25 08:17:26 UTC ---
(In reply to comment #5)
> at the core of the original problem:
> 
> At trans-array.c:6958
> ie. deallocation is not done on procedure entry for results.  I believe that
> this is incorrect for gfortran's pass by reference handling of function
> results.

Actually one needs to be careful: For
  a = f()
which is transferred as
  f(&a)
the "a" may not be deallocated as otherwise pointers to "a" may break. One
probably needs:

a) If "a" is no TARGET:
  deallocate (a)
  f(&a)

b) If "a" is a TARGET
  f(tmp)
  memcpy(a,tmp)

[Bug fortran/42112] overloaded function with allocatable result problem

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-25 08:54:10 UTC ---
(In reply to comment #6)
> One probably needs:
> 
> a) If "a" is no TARGET:
>   deallocate (a)
>   f(&a)

... which has with -fno-realloc-lhs issues when bound checking is enabled. (I
do not know whether we should care.)

> b) If "a" is a TARGET
>   f(tmp)
>   memcpy(a,tmp)

... while this one can be optimized with realloc-lhs to a deallocate + pointer
assignment if the size does not fit (rather than a malloc plus deep copying).

[Bug fortran/42112] overloaded function with allocatable result problem

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> 2010-11-28 11:17:03 UTC ---
Tobias,

(In reply to comment #7)
> (In reply to comment #6)
> > One probably needs:
> > 
> > a) If "a" is no TARGET:
> >   deallocate (a)
> >   f(&a)

At present, this is not done.  I guess that it has to be done by the caller,
rather than the callee, simply because of the issue with TARGET below.

> 
> ... which has with -fno-realloc-lhs issues when bound checking is enabled. (I
> do not know whether we should care.)

Surely, we should just not do the deallocate with -fno-realloc-lhs?

> 
> > b) If "a" is a TARGET
> >   f(tmp)
> >   memcpy(a,tmp)
> 
> ... while this one can be optimized with realloc-lhs to a deallocate + pointer
> assignment if the size does not fit (rather than a malloc plus deep copying).

I guess that this makes sense.  It is very easily done.

I'll put this on the TODO list, for fairly early implementation.  I'll see what
I can do with scalars, first.

Paul

[Bug fortran/42112] overloaded function with allocatable result problem

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This seems to have been fixed at least for 4.8.4.

[Bug fortran/42112] overloaded function with allocatable result problem

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #9)
> This seems to have been fixed at least for 4.8.4.

Hum, if one changes the comment #0 to output the value of p, it outputs 0
instead of 2