* [Bug fortran/42112] overloaded function with allocatable result problem
[not found] <bug-42112-4@http.gcc.gnu.org/bugzilla/>
@ 2010-11-21 12:19 ` pault at gcc dot gnu.org
2010-11-25 8:02 ` pault at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2010-11-21 12:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/42112] overloaded function with allocatable result problem
[not found] <bug-42112-4@http.gcc.gnu.org/bugzilla/>
2010-11-21 12:19 ` [Bug fortran/42112] overloaded function with allocatable result problem pault at gcc dot gnu.org
@ 2010-11-25 8:02 ` pault at gcc dot gnu.org
2010-11-25 8:54 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2010-11-25 8:02 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/42112] overloaded function with allocatable result problem
[not found] <bug-42112-4@http.gcc.gnu.org/bugzilla/>
2010-11-21 12:19 ` [Bug fortran/42112] overloaded function with allocatable result problem pault at gcc dot gnu.org
2010-11-25 8:02 ` pault at gcc dot gnu.org
@ 2010-11-25 8:54 ` burnus at gcc dot gnu.org
2010-11-25 8:59 ` burnus at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-11-25 8:54 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/42112] overloaded function with allocatable result problem
[not found] <bug-42112-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2010-11-25 8:54 ` burnus at gcc dot gnu.org
@ 2010-11-25 8:59 ` burnus at gcc dot gnu.org
2010-11-28 12:46 ` pault at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-11-25 8:59 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/42112] overloaded function with allocatable result problem
[not found] <bug-42112-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2010-11-25 8:59 ` burnus at gcc dot gnu.org
@ 2010-11-28 12:46 ` pault at gcc dot gnu.org
2015-04-17 17:49 ` dominiq at lps dot ens.fr
2015-08-07 20:46 ` mikael at gcc dot gnu.org
6 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2010-11-28 12:46 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/42112] overloaded function with allocatable result problem
[not found] <bug-42112-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2010-11-28 12:46 ` pault at gcc dot gnu.org
@ 2015-04-17 17:49 ` dominiq at lps dot ens.fr
2015-08-07 20:46 ` mikael at gcc dot gnu.org
6 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-04-17 17:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/42112] overloaded function with allocatable result problem
[not found] <bug-42112-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2015-04-17 17:49 ` dominiq at lps dot ens.fr
@ 2015-08-07 20:46 ` mikael at gcc dot gnu.org
6 siblings, 0 replies; 10+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-08-07 20:46 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread