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
