Hmm, for some reasons my first email didn't come through - I have to check at home why. Thus, writing anew:
Regarding: > The Fortran frontend likes to generate calls to realloc, but in one case it > seems > like we can compute the old size, and call a function that does > malloc/memcpy/free instead. I believe the front end always knows the old size. REALLOC seems to be used for two things: a) What you have patched: gfc_grow_array That one seems to be used to extend array constructors which contains arrays, e.g. the rank-one array ... = [1, 2, 3, scalar_f(), array_f(), array(1:n)] where the array-returning function "array_f" and the array section "array(1:n)" might be handled via realloc. b) (Re)allocation on assignment, i.e. A = ... where A is allocatable. The compiler then allocates the left-hand side if unallocated or reallocates it if the array shape, dynamic type or a length type parameter on the right doesn't match the one on the left. (The latter can occur for strings where the RHS has a different length than the LHS; the dynamic type only applies to polymorphic variables and is not yet implemented.) In particular as the compiler may not reallocate if the size has not changed, there should be an array size or character-length check, which isn't far from the REALLOC call. Thus, it would be implementable without too much effort. (The reason that the reallocate is forbidden by the standard if the size already fits is that pointers to "A" do not break due to the changed address when using malloc/free.) * * * Still and mainly for the benefit of (C/C++) code calling realloc directly, I concur with FX and Jakub that one should consider handling realloc later than in the front end. Tobias
