[Fortran-dev][Patch] Some (ubound-lbound+1) -> extent cleanup

[Mikael Morin]

On 15/07/2012 13:24, Tobias Burnus wrote:
> This patch cleans up the source code and generated code ("dump") by
> changing (ubound-lbound+1) calculations to directly taking the "extent".
> Except for a faster -O0 performance and saving some cycles during code
> generation, the code should be the same.
> 
A small, yet welcome simplification :-).

> 
> The only real code change I did was to gfc_grow_array. I didn't
> understand the previous code, I think the current code makes more sense.
> I believe the old code did:
> 
>   desc->extent = desc.extent + extra;
>   realloc (&desc->data, (desc.extent + 1)*element_size);

If you are talking about the old code, I think it does:

desc.ubound[0] += extra;
realloc (desc.data, (desc.ubound[0]+1)*element_size);

> 
> while I think the latter should be "+ extra" and not "+ 1". From the
> callee, I couldn't deduce whether extra is always unity in practice, in
> any case it doesn't look like.
> 
I think the old code is correct, under the assumption that desc.rank is
1, and desc.lbound[0] is 0, which is the case in the contexts where the
functions is called (array constructors).

> 
> For fcncall_realloc_result, I didn't check whether the new code
> effectively matches the old one, I just followed the comment which
> states: "Check that the shapes are the same between lhs and expression.".
> 
I think the old code is:
res_desc.ubound[n] - res_desc.lbound[n]
	- (desc.ubound[n] - desc.lbound[n]) != 0

while the new one is:
res_desc.extent[n] != res.extent[n]


> 
> There are some more cases, but there the code wasn't as obvious. For
> instance "extent = ubound - lbound"; there I was unsure whether that's a
> bug (missing "+1") or valid.
> 
> 
> Build and regtested with no new failures.
> OK for the branch?
> 
Yes, thanks.

Mikael