This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR fortran/35681: First part, fix ELEMENTAL dependency handling for MVBITS
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: "Daniel Kraft" <d at domob dot eu>
- Cc: "Fortran List" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 27 Oct 2008 22:02:36 +0100
- Subject: Re: [Patch, Fortran] PR fortran/35681: First part, fix ELEMENTAL dependency handling for MVBITS
- References: <490605A9.8060306@domob.eu>
Daniel,
I'm a bit pole-axed with the daytime job right now, so my reply must be short.
I have to say that I'me really puzzled about this:
> 6) I could not find a test to verify this (not even one that uses
> gfc_conv_elemental_dependencies) in a quick trial, but I believe the
> handling of the temporary there was wrong, in that it was free'd (if
> allocated on the heap) *before* it was used with internal_unpack, because
> gfc_trans_create_temp_array added the temporary clean-up code to se->post
> and the unpack-call was added to se->post later. In my opinion, this is
> some rather general problem with how post-commands are usually added to
> other post blocks; shouldn't they be added to the top usually rather than to
> the bottom, to get some sort of "nested" scope with inner most pairs of
> pre/post? Well, for now I changed this behaviour inside
> gfc_conv_elemental_dependencies, which corrected problems I got with MVBITS
> tests.
>
The code from the first assignement in elemental_subroutine_3.f90,
which was the first test of this function gives:
{
integer(kind=8) D.1563;
struct array1_mytype parm.5;
struct array1_mytype atmp.3;
struct mytype A.4[6];
void * D.1559;
integer(kind=8) D.1558;
struct array1_integer(kind=8) parm.2;
static integer(kind=8) A.1[6] = {2, 3, 1, 4, 5, 6};
atmp.3.dtype = 297;
atmp.3.dim[0].stride = 1;
atmp.3.dim[0].lbound = 0;
atmp.3.dim[0].ubound = 5;
atmp.3.data = (void *) &A.4;
atmp.3.offset = 0;
D.1558 = 24;
D.1559 = atmp.3.data;
parm.5.dtype = 297;
parm.5.dim[0].lbound = 1;
parm.5.dim[0].ubound = 6;
parm.5.dim[0].stride = 1;
parm.5.data = (void *) &x[0];
parm.5.offset = -1;
D.1563 = 0;
parm.2.dtype = 521;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 6;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) &A.1[0];
parm.2.offset = 0;
{
integer(kind=8) S.6;
S.6 = 0;
while (1)
{
if (S.6 > 5) goto L.1;
{
integer(kind=8) D.1565;
D.1565 = (*(integer(kind=8)[0:] *)
parm.2.data)[parm.2.dim[0].stride * NON_LVALUE_EXPR <S.6>];
myassign (&(*(struct mytype[6] *) atmp.3.data)[S.6 +
D.1563], &x[D.1565 + -1]);
}
S.6 = S.6 + 1;
}
L.1:;
}
_gfortran_internal_unpack (&parm.5, D.1559);
}
As you can see, atmp.3.data is assigned to the stack but it is not
freed either before or after being unpacked. This code, at least is
OK.
Cheers
Paul