This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR53521 - Fix size == 0 handling with reallocate
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Thu, 31 May 2012 11:45:31 +0200
- Subject: Re: [Patch, Fortran] PR53521 - Fix size == 0 handling with reallocate
- References: <4FC739B4.3000009@net-b.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, May 31, 2012 at 11:28:20AM +0200, Tobias Burnus wrote:
> I see two possibilities:
>
>
> 1) FIRST approach: manual freeing/NULL setting; that's the closed
> what is currently done. (Note: It calls free unconditionally;
> "free(0)" is optimized away by the middle end.
> (Note: That requires an update of the "free" count in
> gfortran.dg/allocatable_function_4.f90)
> --------------------------------------------------------------------
> if (D.1887 == 0)
> {
> __builtin_free ((void *) atmp.0.data);
> D.1888 = 0B;
> }
> else
> {
> D.1888 = (integer(kind=4)[0] * restrict) __builtin_realloc
> ((void *) atmp.0.data, D.1887);
> if (D.1888 == 0B && D.1887 != 0)
You wouldn't need to check D.1887 != 0 here, that check has been performed
earlier.
> 2) SECOND approach: Simply removing the NULL setting and just using
> the result which realloc returns; if not NULL, the free() will
> properly handle it.
> --------------------------------------------------------------------
> D.1888 = (integer(kind=4)[0] * restrict) __builtin_realloc
> ((void *) atmp.0.data, D.1887);
> if (D.1888 == 0B && D.1887 != 0)
> {
> _gfortran_os_error (&"Allocation would exceed memory
> limit"[1]{lb: 1 sz: 1});
> }
> atmp.0.data = (void * restrict) D.1888;
> --------------------------------------------------------------------
Yeah, POSIX says on realloc return value:
If size was equal to 0, either NULL or a pointer suitable to be passed to
free() is returned. So, for POSIX compatible realloc implementation the
second approach should be fine.
> I like the second version more. (And I would even consider to get
> rid of the os_error.)
Without the os_error, you'd just crash silently on allocation failures?
Jakub