🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: gmane.comp.gcc.bugs
2 messages
2 total messages Started by "burnus at gcc d Wed, 26 Jan 2011 13:13
[Bug fortran/47474] New: Wrong code with allocatable scalar, allocatable components as function result
#307969
Author: "burnus at gcc d
Date: Wed, 26 Jan 2011 13:13
67 lines
1737 bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?idG474

           Summary: Wrong code with allocatable scalar, allocatable
                    components as function result
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: janus@gcc.gnu.org
            Blocks: 47455


Found as part of PR 47455. For the following program

   function find_y() result(res)
     type(tx), allocatable :: res
     ! do something sensible such as "allocate(res)"
   end function find_y

the dump looks as follows

  find_y ()
  {
    struct tx * res;

    res.i.data = 0B;  /* <<<< WRONG.  */
    res = 0B;
    /* some code.  */
    return res;
  }

If one does not use a RESULT variable but "find_y" as result variable, the dump
looks as follows:

  find_y ()
  {
     __result_find_y.i.data = 0B;  /* Note: 1.  */
     return __result_find_y;
  }

Note 1: Unless "find_y" is used (e.g. "allocate(find_y)") the function is
generated with an empty body.


For some reason, the example program below does not crash here with gfortran
4.5/4.6, but the dump is wrong and I am sure it can cause problems in certain
cases. The example of bug 47455 comment 4 does crash - and I believe(d) that it
is due to this bug.

program test
    type :: tx
        integer, dimension(:), allocatable :: i
    end type tx
    type(tx) :: x
    x = find_y()
    if (allocated(x%i)) call abort()
contains
    function find_y() result(res)
        type(tx), allocatable :: res
        allocate(res)
   end function find_y
end program test
[Bug fortran/47474] Wrong code with allocatable scalar, allocatable components as function result
#307994
Author: "burnus at gcc d
Date: Wed, 26 Jan 2011 15:05
34 lines
1551 bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?idG474

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-26 15:04:53 UTC ---
Patch. The order was wrong; additionally, if there is an allocatable RESULT
variable, it seems to get zero initialized via sym->value or similarly. Thus
the sym->result == result check prevents that two "res = 0B;" lines get added.


--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -4602,16 +4716,18 @@ gfc_generate_function_code (gfc_namespace * ns)
            && sym->attr.function
            && !sym->attr.pointer)
        {
-         if (sym->ts.type == BT_DERIVED
-             && sym->ts.u.derived->attr.alloc_comp)
+         if (sym->attr.allocatable && sym->attr.dimension == 0
+             && sym->result == sym)
+           gfc_add_modify (&init, result, fold_convert (TREE_TYPE (result),
+                                                        null_pointer_node));
+         else if (sym->ts.type == BT_DERIVED
+             && sym->ts.u.derived->attr.alloc_comp
+             && !sym->attr.allocatable)
            {
              rank = sym->as ? sym->as->rank : 0;
              tmp = gfc_nullify_alloc_comp (sym->ts.u.derived, result, rank);
              gfc_add_expr_to_block (&init, tmp);
            }
-         else if (sym->attr.allocatable && sym->attr.dimension == 0)
-           gfc_add_modify (&init, result, fold_convert (TREE_TYPE (result),
-                                                        null_pointer_node));
        }

       if (result == NULL_TREE)
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads