Re: [Ping, Patch 2/2, v3, Fortran, pr60322 a.o.] [OOP] Incorrect bounds on polymorphic dummy array

Re: [Ping, Patch 2/2, v3, Fortran, pr60322 a.o.] [OOP] Incorrect bounds on polymorphic dummy array

[Dominique Dhumieres]

Dear Andre,

If I am not mistaken, this patch make the following test (pr57305, second attachment):

    subroutine add_element_poly(a,e)
      use iso_c_binding
      class(*),allocatable,intent(inout),target :: a(:)
      class(*),intent(in),target :: e
      class(*),allocatable,target :: tmp(:)
      type(c_ptr) :: dummy
      
      interface
        function memcpy(dest,src,n) bind(C,name="memcpy") result(res)
          import
          type(c_ptr) :: res
          integer(c_intptr_t),value :: dest
          integer(c_intptr_t),value :: src
          integer(c_size_t),value :: n
        end function
      end interface

      if (.not.allocated(a)) then
        allocate(a(1), source=e)
      else
        allocate(tmp(size(a)),source=a)
        deallocate(a)
        allocate(a(size(tmp)+1),mold=e)
        dummy = memcpy(loc(a(1)),loc(tmp),sizeof(tmp))
        dummy = memcpy(loc(a(size(tmp)+1)),loc(e),sizeof(e))
      end if
    end subroutine

to give an ICE (a regression):

pr57305_1.f90:24:0:

         dummy = memcpy(loc(a(1)),loc(tmp),sizeof(tmp))
 1
internal compiler error: Segmentation fault: 11

The ICE is caused by sizeof(tmp).

TIA

Dominique

Re: [Ping, Patch 2/2, v3, Fortran, pr60322 a.o.] [OOP] Incorrect bounds on polymorphic dummy array

[Andre Vehreschild]

Ping!

On Fri, 6 Mar 2015 13:38:21 +0100
Andre Vehreschild <vehre@gmx.de> wrote:

> Hi everyone,
> 
> please find attached the latest version of the patch with the comments from
> Dominique via IRC worked in. Those were mostly about clarifying comments and
> style. Nevertheless, thanks for your help Dominique.
> 
> Still basing on the first part of the patch at:
> 
> https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html
> 
> Bootstraps and regtests fine on x86_64-linux-gnu/F20.
> 
> Reviews welcome. 
> 
> Regards,
> 	Andre
> 
> 
> On Wed, 4 Mar 2015 20:30:15 +0100
> Andre Vehreschild <vehre@gmx.de> wrote:
> 
> > Dear all,
> > 
> > during his initial tests Dominique pointed out, that my patch did not fix
> > all issues in the comments of pr60322. This new version of the patch fixes
> > this issue now. The trick is to use a temporary array in the variable
> > association of select type statements. The old code referenced the incoming
> > array directly. This array may have an arbitrary base (i.e. lbound != 1)
> > making indexing very difficult. Creating a temporary array descriptor for
> > the associated variable allows for having the array base set to one (i.e.,
> > lbound == 1) making indexing fairly simple and adhere to the Fortran rules.
> > 
> > The patch boostraps and regtests cleanly on x86_64-linux-gnu/F20. 
> > 
> > Note, you need to apply part 1 of this patch first. Part 1 can be found at:
> > 
> > https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html
> > 
> > Regards,
> > 	Andre
> > 
> > On Thu, 26 Feb 2015 18:17:21 +0100
> > Andre Vehreschild <vehre@gmx.de> wrote:
> > 
> > > Hi all,
> > > 
> > > here is the second part of the patch for pr60322. This patch also
> > > addresses the issue reported in pr64692, ... (more to come).
> > > 
> > > The patch fixes the incorrect bounds of polymorphic arrays used to call
> > > functions and subroutines by using the same mechanism as regular arrays.
> > > In fact most of the code for treating regular arrays is reused by simply
> > > inserting the class array's symbol_attributes and gfc_array_specs into the
> > > same routines, i.e., doing the switching whether a symbol is a class array
> > > or a regular array and assigning the CLASS_DATA(sym).attr or sym.attr to
> > > the symbol_attribute temporary variable introduced by the first part
> > > (same for gfc_array_spec). The temporary array descriptor is then stored
> > > in the tree and extracted were it is needed.
> > > 
> > > This patch furthermore addresses an issue with elemental functions, where
> > > the elemental function was not applied to class array members. By
> > > introducing the temporary array this merely fixed itself.
> > > 
> > > During fixing elemental function application, an issue about using the
> > > polymorphic initializer popped up. The existing code would declare a
> > > variable of the base type (not a reference or pointer to it), assign the
> > > _vptr's _def_init to it and use the _vptr's _copy to copy the initializer
> > > into the object to initialize. This had to be patched to use a pointer for
> > > the variable and the correct addressing to be able to make use of the
> > > polymorphic init.
> > > 
> > > Furthermore is the array offset in certain cases set to be -1. This helped
> > > to get the addressing correct for subarrays of (unlimited polymorphic)
> > > objects, where the array offset is used in a "select type" or other kind
> > > of association and the with the offset set incorrectly wrong elements
> > > from the array were selected.
> > > 
> > > I had to fix two testcases, too:
> > > - finalize_15: We agreed (including checking with other compilers) that
> > > the value of an intent(out) variable should be that of its initializer
> > > and not that of its finalizer.
> > > - finalize_10: By using the temporary arrays the scan-tree-count
> > > expressions had to be adapted, too.
> > > 
> > > Thank you's go to: Tobias, Dominique and Paul for their support during
> > > figuring what it going wrong and thorough testing and to Antony for
> > > reporting the issue.
> > > 
> > > Bootstraps and regtests ok on x86_64-linux-gnu/F20.
> > > 
> > > Regards,
> > > 	Andre
> > 
> > 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de