This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/42112] overloaded function with allocatable result problem
- From: "burnus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Nov 2009 14:22:50 -0000
- Subject: [Bug fortran/42112] overloaded function with allocatable result problem
- References: <bug-42112-17129@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla 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