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
Author: "burnus at gcc d
Date: Wed, 26 Jan 2011 13:13
Date: Wed, 26 Jan 2011 13:13
67 lines
1737 bytes
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
Author: "burnus at gcc d
Date: Wed, 26 Jan 2011 15:05
Date: Wed, 26 Jan 2011 15:05
34 lines
1551 bytes
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