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: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS


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


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