This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] PR fortran/35681: First part, fix ELEMENTAL dependency handling for MVBITS


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]