This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: Alessandro Fanfarillo <fanfarillo dot gcc at gmail dot com>, Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>, gcc-patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Wed, 25 Nov 2015 14:58:03 -0800
- Subject: Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
- Authentication-results: sourceware.org; auth=none
- References: <20150429075505 dot GA21015 at physik dot fu-berlin dot de> <CAHqFgjVtwTSsOtcTT+BedhzWeDBo4EZp7uLPHKz=PBQjTgH5HA at mail dot gmail dot com> <CAGkQGiKre1-4qcokh73HwwLg6iVZnV-T=1J4BKDOJ50OOP=t2Q at mail dot gmail dot com>
Paul
I've bootstrap and regression tested the patch on x86_64-*-freebsd.
I intend to do the same tonight on i386-*-freebsd. After that, I'll
go over the patch as you have done and then intend to commit it.
AFAICT, Tobias is busy with Real-Life (tm) (or taking a much
needed rest from gfortran hacking). tobias, if you would rather
commit the patch, I'm fine with that; otherwise, I'll take care
of it in the next few days.
--
steve
On Wed, Nov 25, 2015 at 11:28:28PM +0100, Paul Richard Thomas wrote:
> Dear Alessandro and Tobias,
>
> I have been through the patch to check for obvious bloopers but can
> find none, as expected given the author :-)
>
> I would dearly like to see the testcases at the same time as the patch
> but.... I think that the commit should be made sooner, rather than
> later. Given its nature, I think that it is pretty safe at this stage
> of the 6.0.0 lifecycle and so I say OK for trunk.
>
> Cheers
>
> Paul
>
> On 25 November 2015 at 18:24, Alessandro Fanfarillo
> <fanfarillo.gcc@gmail.com> wrote:
> > Dear all,
> >
> > in attachment the previous patch compatible with the current trunk.
> > The patch also includes the changes introduced in the latest TS 18508.
> >
> > Built and regtested on x86_64-pc-linux-gnu.
> >
> > PS: I will add the test cases in a different patch.
> >
> > 2015-04-29 9:55 GMT+02:00 Tobias Burnus <tobias.burnus@physik.fu-berlin.de>:
> >> Dear all,
> >>
> >> attached patch fixes a bug and implements EVENTS. I think the patch is
> >> finished, but I still have to extend the test cases, to re-read the
> >> patch and to write a changelog. As I am not sure how soon I will able
> >> to do so, I follow the paradigm: release soon, release often and post
> >> it here. Comments and reviews are welcome.
> >>
> >> The patch fixes two bug in the "errmsg" handling, found by Alessandro:
> >> I don't pass on the address of the actual argument and in libcaf_single,
> >> I copy only 8 characters (sizeof pointer) instead of all of the the
> >> characters of the error message.
> >>
> >> Regarding events: Events is a way to permit barrier/locking-free
> >> programming: One sends the finished data to an other image and then
> >> tells that image that the data is there ("event post(msg_var[idx])").
> >> That image can then either wait for the event by querying the status
> >> on the local variable ("event wait(msg_var)") or only check the status
> >> and if it is not ready do something else (e.g. another iteration);
> >> that's done via "call event_query(msg_var, count)".
> >>
> >> Technically, event_post works like atomic_add(msg_var[idx], 1) and
> >> event_query like "atomic_ref(msg_var, count)". event_wait is the same
> >> as event_query plus a spin/sleep loop waiting for the status change,
> >> followed by an atomic_add(msg_var, -until_count). Except that
> >> event_post/event_wait are image control statements. (Otherwise it
> >> could happen that the event is there before the data for which the
> >> event has been posted.)
> >>
> >> Regarding the implementation in this patch, the limitations are the
> >> same as for locking: Currently, neither lock_type nor event_type
> >> variables are permitted as (nonallocatable) components
> >> of a derived type - and type extension of them also not yet supported.*
> >>
> >> The spec can be found at http://bitly.com/sc22wg5 -> 2015 -> TS draft
> >> or directly at
> >> http://isotc.iso.org/livelink/livelink?func=ll&objId=17064344&objAction=Open
> >>
> >> Tobias
> >>
> >>
> >> * Doing so is not really difficult but I need to handle cases like
> >> the following. For "allocatable" with SOURCE= I also need to handle
> >> it with polymorphic types.
> >>
> >> type t1
> >> type(event_type) :: EV
> >> type(lock_type) :: LK
> >> end type1
> >> type t2
> >> type(t1) :: a(5)
> >> end type t2
> >> type t3
> >> type(t2) :: b(8)
> >> end type t3
> >>
> >> type(t3), save :: caf(3)[*]
> >>
> >> For those, I need to call _gfortran_caf_register for
> >> caf(:)%b(:)%a(:)%ev and caf(:)%b(:)%a(:)%lk
> >> Looping though all array references.
> >>
> >> Similar for
> >> type(t3), allocatable :: caf2(:)[:]
> >> allocate(caf2(n)[*])
> >> for the allocate call.
>
>
>
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
>
> Groucho Marx
--
Steve