This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran, pr60322] was: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
- From: Dominique d'HumiÃres <dominiq at lps dot ens dot fr>
- To: Andre Vehreschild <vehre at gmx dot de>
- Cc: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, Mikael Morin <mikael dot morin at sfr dot fr>, GCC-Fortran-ML <fortran at gcc dot gnu dot org>, GCC-Patches-ML <gcc-patches at gcc dot gnu dot org>, Antony Lewis <antony at cosmologist dot info>
- Date: Wed, 25 Mar 2015 10:43:34 +0100
- Subject: Re: [Patch, Fortran, pr60322] was: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
- Authentication-results: sourceware.org; auth=none
- References: <20150226181717 dot 480e282c at vepi2> <551006FF dot 1080704 at sfr dot fr> <20150323134357 dot 6af740d1 at vepi2> <CAGkQGiK2sp2wqXLMPvg8bc=vgJyr9jryukvwML9Jc9+yt_9odA at mail dot gmail dot com> <20150324180620 dot 3c72960e at vepi2>
Hi Andre,
> Le 24 mars 2015 Ã 18:06, Andre Vehreschild <vehre@gmx.de> a Ãcrit :
>
> Hi all,
>
> I have worked on the comments Mikael gave me. I am now checking for
> class_pointer in the way he pointed out.
>
> Furthermore did I *join the two parts* of the patch into this one, because
> keeping both in sync was no benefit but only tedious and did not prove to be
> reviewed faster.
Are you sure that you attached the right patch? It does not apply on a clean tree unless I apply the patch at
https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html
with minor surgery for gcc/fortran/expr.c.
> Paul, Dominique: I have addressed the LOC issue that came up lately. Or rather
> the patch addressed it already. I feel like this is not tested very well, not
> the loc() call nor the sizeof() call as given in the 57305 second's download.
The ICE is fixed and the LOC issue seems fixed.
> Unfortunately, is that download not runable. I would love to see a test similar
> to that download, but couldn't come up with one, that satisfied me. Given that
> the patch's review will last some days, I still have enough time to come up
> with something beautiful which I will add then.
I have changed the test to
use iso_c_binding
implicit none
real, target :: e
class(*), allocatable, target :: a(:)
e = 1.0
call add_element_poly(a,e)
print *, size(a)
call add_element_poly(a,e)
print *, size(a)
select type (a)
type is (real)
print *, a
end select
contains
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
print *, size(a)
allocate(tmp(size(a)),source=a)
print *, size(a), size(tmp) + 1
print *, loc(a(1)),loc(tmp),sizeof(tmp)
deallocate(a)
! allocate(a(size(tmp)+1),mold=e)
allocate(a(size(tmp)+1),source=e)
print *, size(a), size(tmp)
dummy = memcpy(loc(a(1)),loc(tmp),sizeof(tmp))
dummy = memcpy(loc(a(size(tmp)+1)),loc(e),sizeof(e))
end if
end subroutine
end
As pointed by Paul, I get a segfault at run time if I use the commented line, i.e. âmoldâ instead of âsourceâ.
> Bootstraps and regtests ok on x86_64-linux-gnu/F20.
>
> Regards,
> Andre
Thanks for your work.
Dominique
- References:
- Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
- Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
- Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
- From: Paul Richard Thomas
- [Patch, Fortran, pr60322] was: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array