[Bug libfortran/47775] New: Error on allocatable array returned by function

[Bug libfortran/47775] New: Error on allocatable array returned by function

[fmartinez at gmv dot com]

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

           Summary: Error on allocatable array returned by function
           Product: gcc
           Version: 4.5.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: fmartinez@gmv.com


Created attachment 23370
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23370
Modules, one program and a data file in XML

A function returning an allocatable array seems to have the return array
variable already allocated on entry to the function. The attempt to allocate it
generates the error:
Fortran runtime error: Attempting to allocate already allocated array 'res'

In module t_dom_node_slist_ftl.f90 the commented lines 1358 to 1361 solve the
problem but would expect that function return allocatable arrays are not
allocated on entry (this is the observed behaviour in Intel and g95)

The attached .tar.gz contains the collection of files that reproduce the
problem (sorry, but I have not been able to isolate the problem in a smaller
case).
The compilation command line I have used is:
> /opt/gfortran/bin/gfortran -g  m_string.F90 m_messages.f90 m_util_convert.f90 m_xml.f90 m_dom_element.f90 t_dom_element_pure_tree_ftl.f90 t_string_slist_ftl.f90 m_dom_node.f90 t_dom_node_slist_ftl.f90 m_dom_xpath.f90 m_dom.f90 m_unit_support.f90 unit_m_dom_xpath.f90

The resulting a.out has to be executed with the command line:

> ./ a.out 1

this uses the file unit_m_dom.xml as input

Cheers,

Fran

[Bug fortran/47775] Error on allocatable array returned by function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
          Component|libfortran                  |fortran
           Severity|major                       |normal

--- Comment #1 from kargl at gcc dot gnu.org 2011-02-16 23:48:21 UTC ---
Reset component to fortran and importance to normal.

[Bug fortran/47775] Error on allocatable array returned by function

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-17 07:33:55 UTC ---
If I try the example, I get a segmentation fault in m_string.F90's
string_to_char

The code looks as follows:

elemental function string_to_char( s ) result(res)
[...]
  character(len=size(s%string)) :: res
[...]
  if( allocated(s%string) ) then
    res = transfer( s%string, res )
  else
    res = ''
  end if

The crash happens in the "res =''" line and makes perfectly sense. If the
variable "s%string" is not allocated, it is not surprising that there is a
segfault:

"13.7.156 SIZE (ARRAY [, DIM, KIND])" [...]
"Arguments.
'ARRAY shall be an array of any type. It shall not be an unallocated
allocatable variable or a pointer that is not associated."

[Bug fortran/47775] Error on allocatable array returned by function

[fmartinez at gmv dot com]

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

--- Comment #3 from Fran Martinez Fadrique <fmartinez at gmv dot com> 2011-02-17 09:04:14 UTC ---
The problem reported on the string_to_char is correct in the sense that if
invoked with a non allocated string it would cause a segfault.
When I run the case I get beore that the reported problem in the code

! Allocate memory for returned array
!  if( allocated(res) ) then
!    deallocate(res)
!  end if
!  allocate( res( size(list) ), stat=status )
  allocate( res( size(list) ) )
  if( status == 0 ) then

!   Initialise navigation pointer
    lptr => list%first

There is one invocation when the res array is already allocated when entering
the routine.
If I uncomment the commented lines and comment
  allocate( res( size(list) ) )
then I run to the very end because I protect the case when res is already
allocated on entry to the function.
I would have liked to isolate the problem in a simpler case but I really could
not.
If you let me know when the segfault happens (the call stack) in your case I
can maybe simplify the high level unit test to remove any secondary effect from
the trouble I report.

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Summary|Error on allocatable array  |Wrong code with allocatable
                   |returned by function        |function RESULT and GENERIC
                   |                            |interfaces

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-17 10:23:21 UTC ---
Reduced test case: The crucial point is the GENERIC interface.

interface gen
  procedure foo
end interface gen

integer :: bar(2)
bar = gen()

contains
  function foo()
    integer, allocatable :: foo(:)
    allocate(foo(2))
  end function foo
end

 * * *

(In reply to comment #3)
> The problem reported on the string_to_char is correct in the sense that if
> invoked with a non allocated string it would cause a segfault.

Well, it did here - and the failure came before the failure you reported ...

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-17 23:45:14 UTC ---
If one looks closer at "se->direct_byref" in gfc_conv_procedure_call, one sees
that in the generic case "se->direct_byref" is 1 while in the specific-call
case it is 0. (Thus, in the specific case, always a temporary is generated.)

There might be no need for a temporary, if the LHS is allocatable without the
TARGET attribute.

I am not sure how far automatic realloc is properly handled for
allocatable-returning functions, but there might be room for optimization if
the size changes or the LHS is not TARGET.


Untested patch:
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5373,8 +5373,9 @@ arrayfunc_assign_needs_temporary (gfc_expr * expr1,
gfc_expr * expr2)
     return true;

   /* Functions returning pointers need temporaries.  */
-  if (expr2->symtree->n.sym->attr.pointer 
-      || expr2->symtree->n.sym->attr.allocatable)
+  if (expr2->value.function.esym
+      && (expr2->value.function.esym->attr.pointer 
+         expr2->value.function.esym->attr.allocatable))
     return true;

   /* Character array functions need temporaries unless the

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-17 23:55:59 UTC ---
Janus, Paul: Do you think the patch in comment 5 (with added "||") is OK? Or
does one need to take care about thinks like intrinsics, proc-pointer
(components) and type-bound procedures?

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2011-02-18 10:12:06 UTC ---
(In reply to comment #6)
> Janus, Paul: Do you think the patch in comment 5 (with added "||") is OK? Or
> does one need to take care about thinks like intrinsics, proc-pointer
> (components) and type-bound procedures?

Well, it will surely not handle PPCs (and TBPs). Normal proc-pointers should be
ok, I guess. Maybe 'gfc_expr_attr' will help here?

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> 2011-02-18 11:06:14 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > Janus, Paul: Do you think the patch in comment 5 (with added "||") is OK? Or
> > does one need to take care about thinks like intrinsics, proc-pointer
> > (components) and type-bound procedures?
> 
> Well, it will surely not handle PPCs (and TBPs). Normal proc-pointers should be
> ok, I guess. Maybe 'gfc_expr_attr' will help here?

Tobias and Janus,

I think that Janus's remarks are correct - especially wrt to gfc_expr_attr.

Paul

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-18 21:35:47 UTC ---
Author: burnus
Date: Fri Feb 18 21:35:44 2011
New Revision: 170289

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170289
Log:
2011-02-18  Tobias Burnus

        PR fortran/47775
        * trans-expr.c (arrayfunc_assign_needs_temporary): Use
        esym to check whether the specific procedure returns an
        allocatable or pointer.

2011-02-18  Tobias Burnus

        PR fortran/47775
        * gfortran.dg/func_result_6.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/func_result_6.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-19 08:57:13 UTC ---
Author: burnus
Date: Sat Feb 19 08:57:10 2011
New Revision: 170309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170309
Log:
2011-02-19  Tobias Burnus

        PR fortran/47775
        * trans-expr.c (arrayfunc_assign_needs_temporary): Use
        esym to check whether the specific procedure returns an
        allocatable or pointer.

2011-02-19  Tobias Burnus

        PR fortran/47775
        * gfortran.dg/func_result_6.f90: New.


Added:
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/func_result_6.f90
Modified:
    branches/gcc-4_5-branch/gcc/fortran/ChangeLog
    branches/gcc-4_5-branch/gcc/fortran/trans-expr.c
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-19 11:27:55 UTC ---
Author: burnus
Date: Sat Feb 19 11:27:52 2011
New Revision: 170312

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170312
Log:
2011-02-19  Tobias Burnus

        PR fortran/47775
        * trans-expr.c (arrayfunc_assign_needs_temporary): Use
        esym to check whether the specific procedure returns an
        allocatable or pointer.

2011-02-19  Tobias Burnus

        PR fortran/47775
        * gfortran.dg/func_result_6.f90: New.


Added:
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/func_result_6.f90
Modified:
    branches/gcc-4_4-branch/gcc/fortran/ChangeLog
    branches/gcc-4_4-branch/gcc/fortran/trans-expr.c
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-19 11:28:30 UTC ---
Fixed on the trunk (4.6) and on the 4.4 and 4.5 branches.

Thanks for the report!