Request for help with the scalarizer

Tobias Burnus burnus@net-b.de
Wed Aug 22 17:20:00 GMT 2012


Dear all,

first, a question to Mikael (and others knowing the scalarizer): How to 
properly fix the following:

implicit none
REAL qss(3)
REAL, ALLOCATABLE :: qj(:,:)
INTEGER             :: qcount
qss(:)=qj(:,qcount)
end

For that one calls gfc_cleanup_loop (&loop) - and in gfc_free_ss:

     case GFC_SS_SECTION:
       for (n = 0; n < ss->dimen; n++)
         {
           if (ss_info->data.array.subscript[ss->dim[n]])
             gfc_free_ss_chain (ss_info->data.array.subscript[ss->dim[n]]);
         }

The problem is:

(gdb) p  ss->dimen
$8 = 1
(gdb) p ss->dim[0]
$9 = 0
(gdb) p ss->info->data.array.subscript
$10 = {0x0, 0x15f37f0, 0x0, 0x0, 0x0, 0x0, 0x0}

The question is now whether ss->dim[0] should be 1 instead of 0, then 
the bug is in gfc_walk_array_ref's AR_SECTION: -> DIMEN_ELEMENT 
handling. 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.


Secondly, I tried to to fix all gfc_ss mem leaks (including PR54350, 
which I accidentally introduced).

The attached patch works nicely for the test suite (except for 
realloc_on_assign_*.f90 aka PR54350), it also fixes the leaks in some 
real-world test  files. And it compiles nearly all polyhedron examples.

However: It fails to compile rnflow of Polyhedron 2005. Namely, one 
enters an endless loop in gfc_conv_ss_startstride with the following 
backtrace. Obviously, one has freed too much memory to early. Namely:

   ss = gfc_walk_expr (expr1);
   gfc_conv_array_parameter (&se, expr1, ss, false, NULL, NULL, NULL);
           realloc_lhs_loop_for_fcn_call (&se, &expr1->where, &ss, &loop);

With the current patch, gfc_conv_array_parameter always frees "ss"; 
before, it only freed ss by calling gfc_conv_expr_descriptor.


How to solve that? A partial ss freeing is rather bad as one cannot 
detect whether "ss" has been freed or not. One solution would be that 
gfc_conv_expr_descriptor no longer frees the memory - i.e. the caller 
has to do the duty. That's probably the most invasive patch, but at 
least it makes the code clearer.

Suggestions?


#0  gfc_conv_ss_startstride (loop=0x7fffffffd8a0) at 
/projects/tob/gcc-git/gcc/gcc/fortran/trans-array.c:3861
#1  0x000000000063b105 in realloc_lhs_loop_for_fcn_call 
(loop=0x7fffffffd8a0, ss=<synthetic pointer>, where=0x183a990, 
se=0x7fffffffd850)
     at /projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:6597
#2  gfc_trans_arrayfunc_assign (expr1=0x183a940, 
expr2=expr2@entry=0x183e080) at 
/projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:6778
#3  0x000000000063c4c2 in gfc_trans_assignment (expr1=0x183a940, 
expr2=0x183e080, init_flag=<optimized out>, dealloc=<optimized out>)
     at /projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:7441
#4  0x0000000000602be2 in trans_code (code=0x183ee10, cond=0x0) at 
/projects/tob/gcc-git/gcc/gcc/fortran/trans.c:1312
#5  0x0000000000629937 in gfc_generate_function_code (ns=<optimized 
out>) at /projects/tob/gcc-git/gcc/gcc/fortran/trans-decl.c:5346


Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 5179 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20120822/0c098f4e/attachment.bin>


More information about the Fortran mailing list