Fortran 'allocatable': 'gfc_allocate_using_malloc' vs. plain 'BUILT_IN_MALLOC'

[Janne Blomqvist]

On Wed, Jun 5, 2019 at 5:41 PM Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
>
> On Wed, Jun 05, 2019 at 11:06:11AM +0200, Thomas Schwinge wrote:
> >
> > Thanks for educating me in PR90741 "Unreachable second '__builtin_malloc'
> > for scalar 'allocatable'" -- I didn't know about the default
> > '-frealloc-lhs' behavior.
>
> Default behavior is required by the Fortran 2003 or 2008 standard.
> I don't remember which standard introduced the behavior.
>
> >
> > One additional question:
> >
> > The 'allocate' statement uses 'gfc_allocate_using_malloc' (via
> > 'gfc_allocate_allocatable'), but '-frealloc-lhs' uses plain
> > 'BUILT_IN_MALLOC'.  The former does an "Allocation would exceed memory
> > limit" ('NULL' return) check, the latter doesn't.  (Likewise the latter
> > for other 'BUILT_IN_MALLOC' uses in 'gcc/fortran/'.)  Is this difference
> > intentional?
> >
>
> I don't know the answer, but can conjecture.
>
> The ALLOCATE statement was implemented well prior to (re)allocation
> on assignment.  It has a long list of contraints to check, so
> a number of error conditions can happen.  Checking for an out of
> memory condition was likely added as a preemptive condition to
> graceful terminate the program.  When (re)allocation on assignment
> was added to gfortran, it takes a different code path through the
> compiler, because some of the features of the ALLOCATE statement
> aren't needed (e.g., optional type spec, SOURCE=, MOLD=) and many/most
> constraints on the ALLOCATE statement do not apply.  For
> (re)allocation on assignment, the requirments are the LHS has
> the ALLOCATABLE attribute and the rank of the LHS matches the
> rank on the RHS.  BUILT_IN_MALLOC was likely used as it was convenient.
>
> or
>
> Different people(s) separated by a number of years implemented the
> two features.

Back in the day ALLOCATE was implemented via a call to libgfortran,
which in turn called malloc(). At some point this was changed to call
malloc directly, in order to benefit from whatever optimizations might
be possible to __builtin_malloc(). But probably the code partly still
reflects that. Many years later the "reallocate on assignment" was
implemented, likely by someone else as Steve guessed.

As for the general question of whether we should check for malloc
returning NULL, I do think we should, although the benefit is likely
minor due to overcommit.



-- 
Janne Blomqvist