Request for help with the scalarizer

[Tobias Burnus]

On 08/22/2012 09:56 PM, Mikael Morin wrote:
> On 22/08/2012 19:19, Tobias Burnus wrote:
>> Or whether the gfc_free_ss handling is wrong. A brute-force
>> method would be to walk all MAX_DIMENSION elements of
>> ss->info->data.array.subscript.
> Yes, that's the way it should be. For example gfc_add_loop_ss_code has
> already one "brute force" loop about subscripts:
>
> 	case GFC_SS_SECTION:
> 	  /* Add the expressions for scalar and vector subscripts.  */
> 	  for (n = 0; n < GFC_MAX_DIMENSIONS; n++)
> 	    if (info->subscript[n])
> 	      gfc_add_loop_ss_code (loop, info->subscript[n], true, where);

That won't work with  gfortran.dg/inline_sum_1.f90 for the ninth call 
from gfc_conv_intrinsic_anyall's to gfc_cleanup_loop. There one has:

(gdb) p loop->ss->dimen
$14 = 2
(gdb) p loop->ss->dim
$15 = {1, 2, 0, 0, 0, 0, 0}
(gdb) p loop->ss->info->data.array.subscript
$16 = {0x1609290, 0x165aeb0, 0x165a790, 0x0, 0x0, 0x0, 0x0}

and

(gdb) p loop->nested->ss->dimen
$17 = 1
(gdb) p loop->nested->ss->dim
$18 = {0, 0, 0, 0, 0, 0, 0}
(gdb) p loop->nested->ss->info->data.array.subscript
$19 = {0x1609290, 0x165aeb0, 0x165a790, 0x0, 0x0, 0x0, 0x0}

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.


> In general, I prefer having allocation and deallocation at the same
> scope for clarity. In gfc_conv_expr_descriptor, it makes some sense to
> throw away ss once it has been used for a loop, so it would be better to
> have the allocation happen there too.
> I have reviewed gfc_conv_expr_descriptor calls, and unless I missed
> some, they all follow the same pattern:
> ss = gfc_walk_expr (expr);
> ...
> gfc_init_se (&se, ...);
> ...
> gfc_conv_expr_descriptor (&se, expr, ss);
>
> This shows that ss is redundant with expr, so I think the walking should
> be internal to gfc_conv_expr_descriptor, the ss argument should be
> removed, and then gfc_conv_array_parameter doesn't need ss any more. I
> believe it would solve your problem, and make allocation and cleanup
> happen in the same function, which is nice. I don't think it would avoid
> invasive changes though.
>

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.

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.)


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?

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ss-cleanup.diff
Type: text/x-patch
Size: 36880 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20120823/d3254dca/attachment.bin>