Re: [PATCH] Fix PR42958

[Richard Guenther <rguenther at suse dot de>]

On Thu, 29 Apr 2010, Tobias Burnus wrote:

> On 04/29/2010 12:28 PM, Richard Guenther wrote:
> 
> Thus I'd appreciate if somebody would add a testcase verifying
> that a zero allocation still results in a successful allocated
> check
>   
> 
> 
> I think there is already some testcase, though one may need to create some
> more. The problem is that zero-sized arrays are really special cases and
> thus it is easy to forgot about them.
> 
> Unconditional free should be ok for gfortran emitted calls as
> I understand they are internal calls and user code can have
> manual allocated checks if they want to omit the call for
> speed reasons (thus, no reason to duplicate that in the
> middle-end interface).
>   
> 
> 
> For the first part I agree, however, I do not understand the second part.
> Assume:
> ...
> allocate(array(1000))
> ...
> deallocate(array)
> ! <<< here the automatic deallocation happens
> end
> 
> How can the user do anything about the automatic deallocation? If the
> compiler does not insert any "if(array.data != NULL)" condition before the
> "end", _builtin_free will always be called - the user has no choice (except
> of omitting the explicit deallocation). I think Fortran 90 required* the
> explicit deallocation while it is optional in Fortran 95, but in any case a
> lot of real-world code explicit "DEALLOCATE" - and often is makes sense to
> do it oneself early instead of keeping the memory until the allocatable
> variable leaves the scope. Another case of array==NULL are "if (something)
> {allocate(...)}" blocks where for something==false no allocation happens.
> 
> One can decide that the performance penalty of calling "free" with a NULL
> pointer is small enough to play no role (POSIX allows calling free with a
> NULL pointer), but not with the "user code can" argument.
> 
> Probably, it does not really matter as the performance critical if-NULL
> checks are in loops, but there no sane user would place ALLOCATE/DEALLOCATEs
> there and only temporaries generate malloc/free calls, where the temporary
> variable should never point to NULL.

Hmm, ok.  I can deal with conditional free easily I guess (and
the middle-end should optimize free (p); p = 0; if (p) free (p);
already, not so free (p); p = 0; free (p); though - but that's
very easy to add as well).

Can you paste me a compilable testcase with allocate () deallocate ()
like the above snippet?

Richard.

> Tobias
> 
> * I rechecked - and found in Wikipedia: "Clearly defined that ALLOCATABLE
> arrays are automatically deallocated when they go out of scope." Thus, the
> automatic deallocation seemingly also happened with Fortran 90, but the
> users and compiler writers did not know for sure.
> 
> 

-- 
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex