Fortran 'allocatable': 'gfc_allocate_using_malloc' vs. plain 'BUILT_IN_MALLOC'
Steve Kargl
sgk@troutmask.apl.washington.edu
Wed Jun 5 14:41:00 GMT 2019
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.
--
Steve
More information about the Fortran
mailing list