2012-01-31 Paul Thomas <pa...@gcc.gnu.org>
PR fortran/52012
* trans-expr.c (fcncall_realloc_result): Correct calculation of
result offset.
2012-01-31 Paul Thomas <pa...@gcc.gnu.org>
PR fortran/52012
* gfortran.dg/realloc_on_assign_10.f90: New test.
Committed as revision 183757.
>From 7.4.1.3 of the F2003 standard
....snip....
If variable is an allocated allocatable variable, it is deallocated if
expr is an array of different shape or any of the corresponding length
type parameter values of variable and expr differ. If variable is or
becomes an unallocated allocatable variable, then it is allocated with
each deferred type parameter equal to the corresponding type
parameters of expr , with the shape of expr , and with each lower
bound equal to the corresponding element of LBOUND(expr ).
In this case, 'expr' is reshape(b,shape(a),order=[3,2,1]), so the
question is what should the lower bounds of this expression be?
I would say that if 'variable' is already allocated, the existing
lower bounds should be used, in order to be fortran-95 compatable. In
practical terms, this means that the lbounds should be unity, which is
what is implemented. I think that if 'variable' was not already
allocated, the lower bounds should be zero.
Note though, we are not in fact doing a reallocate on assign with
intrinsic functions but are unconditionally deallocating the lhs and
allocating afresh. To be done correctly realloc_lhs needs to be added
to compile_options_t in libgfortran.h and all the intrinsic array
functions modified to implement realloc on assign; ie. when ret->data
is NULL continue as at present but, where it is not and the option is
set, reallocate after checking if the data size is already correct or
not.
I will set about implementing that before 4.8.0 so that it can be
introduced immediately. There are only 48 references to
internal_malloc_size that need checking :-)
Cheers
Paul
