This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Request for help with the scalarizer
Hello,
as usual the devil is in the details.
On 23/08/2012 11:43, Tobias Burnus wrote:
> Thus, without the patch, one first frees the second and third element
> and then the first, with the brute-force approach, one tries to free all
> subscripts twice.
Indeed. Then the switch should be moved to free_ss_info (which is a more
appropriate place anyway).
> I tried it - and it mostly works okay. I was running into some cases
> where the expression could be a variable (expr->rank != 0 -> array) but
> also a procedure/procedure pointer. For those, I have now an extra
> gfc_walk_expr.
Huh, so expr->rank is wrong? How odd!
I guess your fix is good enough for now. We can consider later using a
procedural gfc_is_scalar (whatever the name) predicate mimicking
gfc_walk_expr but returning a boolean and avoiding the alloc'n'free if
that becomes a concern.
>
> Regarding realloc LHS, I am not quite sure how that's supposed to be
> handled - see FIXME. (As there is no realloc failure except for the
> known realloc_on_assign_5.f03, it might work by simply removing "ss" for
> good.)
Hum, I'm not sure. See the usage of is_alloc_lhs in
gfc_conv_procedure_call: se->ss is the rhs (is it?), and we look at
se->ss->loop_chain. If I understand it correctly, we assume that we are
at the end of the rhs chain and both the lhs and the rhs have been added
to the loop, so loop_chain points to lhs. By the way this looks fragile.
>
>
> All in all, the attached patch works reasonably well, however:
>
> - It enters an endless loop for Polyhedron 2005's aermod.f90 (module
> reading). [That's really odd!]
> - I get the following test-case suite failures:
> gfortran.dg/pointer_remapping_4.f03
> gfortran.dg/pointer_remapping_5.f08
> gfortran.dg/pointer_remapping_6.f08
> gfortran.dg/array_function_5.f90
> gfortran.dg/char_transpose_1.f90
> gfortran.fortran-torture/execute/intrinsic_matmul.f90
> gfortran.dg/inline_sum_2.f90
> gfortran.dg/inline_transpose_1.f90
> gfortran.dg/matmul_3.f90
> gfortran.dg/matmul_4.f90
> gfortran.dg/transpose_conjg_1.f90
> gfortran.dg/transpose_optimization_2.f90
> gfortran.dg/reshape_transpose_1.f90
> gfortran.dg/ret_array_1.f90
>
> Comments? Suggestions and proposed fixes regarding the failures?
>
For the transpose case in gfc_conv_expr_descriptor you reported in the
other mail, the tail call optimization could be made by hand at the
beginning of the function to avoid keeping the ss argument (and throwing
away this patch).
I'll help investigate the other failures tonight.
Mikael