Re: [libfortran, patch] fix for PR 19106

[Thomas Koenig <Thomas dot Koenig at online dot de>]

Tobias Schlüter wrote:

> > This was done correctly in one function in ifunction.c, all I did
> > was copy that part of the code to the second one.  Assigned to
> > the FSF while I await copyright papers to sign.
> 
> I think this should be isolated into a function of its own, which should go
> into runtime/memory.c.  While those functions are generated,  it is code
> that's needed in several places -- like the similar problem I'm working on
> (but unfortunately not making much progress) -- but also in the file you're
> editing, where you're duplicating code, and given the overhead of memory
> allocation, I don't think that an additional function call (which will most
> probably be a tailcall anyway) will matter.

I can do that, but I have a few questions:

This code uses the array "extents" that is precomputed
in ifunction.m4.  Recomputing them isn't a big deal, but does
introduce a little additional overhead.

The array descriptors are typed.  Using gfc_array_void would be
very ugly, require unnecessary casts and probably cause breakage.
It would probably best to generate these functions, too.  Hmm...

Finally, there's the question of interface.  I am currently thinking
of making this into two functions, one (for the i4 type)

void gfc_alloc_temparray_i4(gfc_array_i4 *arr)

in which arr has its dtype, dim.lbound and dum.ubound filled out
correctly, and which calculates the strides and the size of the
array and allocates memory.

The second one would be

void gfc_alloc_temparray_dim_i4(const gfc_array_i4 *template,
	gfc_array_i4 *target, int dim)

which fills out the type, lbounds and ubounds, then calls
gfc_alloc_temparray_i4() with a tailcall.

Opinions?