Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Committed on gcc-5-branch as rev. 233379. 2016-02-12 0:04 GMT+01:00 Alessandro Fanfarillo : > Dear all, > > in attachment the EVENT patch for gcc-5-branch directly back-ported > from the trunk. > > Built and regtested on x86_64-pc-linux-gnu. I plan to commit this > patch this evening (Feb 12th, CET). > > Cheers, > > Alessandro > > 2015-12-17 17:19 GMT+01:00 Alessandro Fanfarillo : >> Great! Thanks. >> >> 2015-12-17 15:57 GMT+01:00 Steve Kargl : >>> On Thu, Dec 17, 2015 at 01:22:06PM +0100, Alessandro Fanfarillo wrote: I've noticed that this patch has been applied only on trunk and not on the gcc-5-branch. Is it a problem to include EVENTS in gcc-5? >>> >>> No problem. When I applied the EVENTS patch to trunk, >>> the 5.3 release was being prepared. I was going to >>> wait for a week or two after 5.3 came out, then apply >>> the patch. Now that you have commit access, feel >>> free to back port the patch. Rememer to post the >>> patch that you commit to both the fortran and gcc-patches >>> list. >>> >>> -- >>> Steve
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Dear all,
in attachment the EVENT patch for gcc-5-branch directly back-ported
from the trunk.
Built and regtested on x86_64-pc-linux-gnu. I plan to commit this
patch this evening (Feb 12th, CET).
Cheers,
Alessandro
2015-12-17 17:19 GMT+01:00 Alessandro Fanfarillo :
> Great! Thanks.
>
> 2015-12-17 15:57 GMT+01:00 Steve Kargl :
>> On Thu, Dec 17, 2015 at 01:22:06PM +0100, Alessandro Fanfarillo wrote:
>>>
>>> I've noticed that this patch has been applied only on trunk and not on
>>> the gcc-5-branch. Is it a problem to include EVENTS in gcc-5?
>>>
>>
>> No problem. When I applied the EVENTS patch to trunk,
>> the 5.3 release was being prepared. I was going to
>> wait for a week or two after 5.3 came out, then apply
>> the patch. Now that you have commit access, feel
>> free to back port the patch. Rememer to post the
>> patch that you commit to both the fortran and gcc-patches
>> list.
>>
>> --
>> Steve
commit 9504c4c79accddeb6e2386c9bf60d651c3d8f627
Author: Alessandro Fanfarillo
Date: Thu Feb 11 11:24:53 2016 +
Events patch backported from gcc-trunk
diff --git ./gcc/fortran/check.c ./gcc/fortran/check.c
index 3196420..049a6fb 100644
--- ./gcc/fortran/check.c
+++ ./gcc/fortran/check.c
@@ -1157,6 +1157,59 @@ gfc_check_atomic_cas (gfc_expr *atom, gfc_expr *old,
gfc_expr *compare,
return true;
}
+bool
+gfc_check_event_query (gfc_expr *event, gfc_expr *count, gfc_expr *stat)
+{
+ if (event->ts.type != BT_DERIVED
+ || event->ts.u.derived->from_intmod != INTMOD_ISO_FORTRAN_ENV
+ || event->ts.u.derived->intmod_sym_id != ISOFORTRAN_EVENT_TYPE)
+{
+ gfc_error ("EVENT argument at %L to the intrinsic EVENT_QUERY "
+"shall be of type EVENT_TYPE", &event->where);
+ return false;
+}
+
+ if (!scalar_check (event, 0))
+return false;
+
+ if (!gfc_check_vardef_context (count, false, false, false, NULL))
+{
+ gfc_error ("COUNT argument of the EVENT_QUERY intrinsic function at %L "
+"shall be definable", &count->where);
+ return false;
+}
+
+ if (!type_check (count, 1, BT_INTEGER))
+return false;
+
+ int i = gfc_validate_kind (BT_INTEGER, count->ts.kind, false);
+ int j = gfc_validate_kind (BT_INTEGER, gfc_default_integer_kind, false);
+
+ if (gfc_integer_kinds[i].range < gfc_integer_kinds[j].range)
+{
+ gfc_error ("COUNT argument of the EVENT_QUERY intrinsic function at %L "
+"shall have at least the range of the default integer",
+&count->where);
+ return false;
+}
+
+ if (stat != NULL)
+{
+ if (!type_check (stat, 2, BT_INTEGER))
+ return false;
+ if (!scalar_check (stat, 2))
+ return false;
+ if (!variable_check (stat, 2, false))
+ return false;
+
+ if (!gfc_notify_std (GFC_STD_F2008_TS, "STAT= argument to %s at %L",
+ gfc_current_intrinsic, &stat->where))
+ return false;
+}
+
+ return true;
+}
+
bool
gfc_check_atomic_fetch_op (gfc_expr *atom, gfc_expr *value, gfc_expr *old,
diff --git ./gcc/fortran/dump-parse-tree.c ./gcc/fortran/dump-parse-tree.c
index 83ecbaa..c886010 100644
--- ./gcc/fortran/dump-parse-tree.c
+++ ./gcc/fortran/dump-parse-tree.c
@@ -1659,6 +1659,33 @@ show_code_node (int level, gfc_code *c)
}
break;
+case EXEC_EVENT_POST:
+case EXEC_EVENT_WAIT:
+ if (c->op == EXEC_EVENT_POST)
+ fputs ("EVENT POST ", dumpfile);
+ else
+ fputs ("EVENT WAIT ", dumpfile);
+
+ fputs ("event-variable=", dumpfile);
+ if (c->expr1 != NULL)
+ show_expr (c->expr1);
+ if (c->expr4 != NULL)
+ {
+ fputs (" until_count=", dumpfile);
+ show_expr (c->expr4);
+ }
+ if (c->expr2 != NULL)
+ {
+ fputs (" stat=", dumpfile);
+ show_expr (c->expr2);
+ }
+ if (c->expr3 != NULL)
+ {
+ fputs (" errmsg=", dumpfile);
+ show_expr (c->expr3);
+ }
+ break;
+
case EXEC_LOCK:
case EXEC_UNLOCK:
if (c->op == EXEC_LOCK)
diff --git ./gcc/fortran/expr.c ./gcc/fortran/expr.c
index c90e823..2e74375 100644
--- ./gcc/fortran/expr.c
+++ ./gcc/fortran/expr.c
@@ -4864,6 +4864,19 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer,
bool alloc_obj,
return false;
}
+ /* TS18508, C702/C203. */
+ if (!alloc_obj
+ && (attr.lock_comp
+ || (e->ts.type == BT_DERIVED
+ && e->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
+ && e->ts.u.derived->intmod_sym_id == ISOFORTRAN_EVENT_TYPE)))
+{
+ if (context)
+ gfc_error ("LOCK_EVENT in variable definition context (%s) at %L",
+ context, &e->where);
+ return false;
+}
+
/* INTENT(IN) dummy argument. Check this, unless the object itself is the
component of sub-component of a pointer; we need to distinguish
assignment to a pointer component from pointer-assignment to a pointer
diff --git
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Great! Thanks. 2015-12-17 15:57 GMT+01:00 Steve Kargl : > On Thu, Dec 17, 2015 at 01:22:06PM +0100, Alessandro Fanfarillo wrote: >> >> I've noticed that this patch has been applied only on trunk and not on >> the gcc-5-branch. Is it a problem to include EVENTS in gcc-5? >> > > No problem. When I applied the EVENTS patch to trunk, > the 5.3 release was being prepared. I was going to > wait for a week or two after 5.3 came out, then apply > the patch. Now that you have commit access, feel > free to back port the patch. Rememer to post the > patch that you commit to both the fortran and gcc-patches > list. > > -- > Steve
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
On Thu, Dec 17, 2015 at 01:22:06PM +0100, Alessandro Fanfarillo wrote: > > I've noticed that this patch has been applied only on trunk and not on > the gcc-5-branch. Is it a problem to include EVENTS in gcc-5? > No problem. When I applied the EVENTS patch to trunk, the 5.3 release was being prepared. I was going to wait for a week or two after 5.3 came out, then apply the patch. Now that you have commit access, feel free to back port the patch. Rememer to post the patch that you commit to both the fortran and gcc-patches list. -- Steve
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Hi, I've noticed that this patch has been applied only on trunk and not on the gcc-5-branch. Is it a problem to include EVENTS in gcc-5? 2015-12-02 23:00 GMT+01:00 Steve Kargl : > Committed as revision 231208. > > Alessandro, Tobias, is this a candidate for a commit to > the 5-branch when it is re-opened? > > -- > steve > > On Wed, Dec 02, 2015 at 03:16:05PM +0100, Alessandro Fanfarillo wrote: >> *PING* >> >> 2015-11-26 17:51 GMT+01:00 Steve Kargl : >> > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo 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. >> >> >> > >> > I have now built and regression tested the patch on >> > x86_64-*-freebsd and i386-*-freebsd. There were no >> > regressions. In reading through the patch, nothing >> > jumped out at me as suspicious/wrong. Tobias, this >> > is OK to commit. If you don't committed by Sunday, >> > I'll do it for you. >> > >> > -- >> > steve > > -- > Steve
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Yes please. Thanks. 2015-12-02 23:00 GMT+01:00 Steve Kargl : > Committed as revision 231208. > > Alessandro, Tobias, is this a candidate for a commit to > the 5-branch when it is re-opened? > > -- > steve > > On Wed, Dec 02, 2015 at 03:16:05PM +0100, Alessandro Fanfarillo wrote: >> *PING* >> >> 2015-11-26 17:51 GMT+01:00 Steve Kargl : >> > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo 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. >> >> >> > >> > I have now built and regression tested the patch on >> > x86_64-*-freebsd and i386-*-freebsd. There were no >> > regressions. In reading through the patch, nothing >> > jumped out at me as suspicious/wrong. Tobias, this >> > is OK to commit. If you don't committed by Sunday, >> > I'll do it for you. >> > >> > -- >> > steve > > -- > Steve
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Committed as revision 231208. Alessandro, Tobias, is this a candidate for a commit to the 5-branch when it is re-opened? -- steve On Wed, Dec 02, 2015 at 03:16:05PM +0100, Alessandro Fanfarillo wrote: > *PING* > > 2015-11-26 17:51 GMT+01:00 Steve Kargl : > > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo 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. > >> > > > > I have now built and regression tested the patch on > > x86_64-*-freebsd and i386-*-freebsd. There were no > > regressions. In reading through the patch, nothing > > jumped out at me as suspicious/wrong. Tobias, this > > is OK to commit. If you don't committed by Sunday, > > I'll do it for you. > > > > -- > > steve -- Steve
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
*PING* 2015-11-26 17:51 GMT+01:00 Steve Kargl : > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo 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. >> > > I have now built and regression tested the patch on > x86_64-*-freebsd and i386-*-freebsd. There were no > regressions. In reading through the patch, nothing > jumped out at me as suspicious/wrong. Tobias, this > is OK to commit. If you don't committed by Sunday, > I'll do it for you. > > -- > steve
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Hi all,
in attachment the patch for tests and missing functions in
libcaf_single (needed by the test suite).
Built and regtested on x86_64-pc-linux-gnu.
2015-11-26 17:51 GMT+01:00 Steve Kargl :
> On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo 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.
>>
>
> I have now built and regression tested the patch on
> x86_64-*-freebsd and i386-*-freebsd. There were no
> regressions. In reading through the patch, nothing
> jumped out at me as suspicious/wrong. Tobias, this
> is OK to commit. If you don't committed by Sunday,
> I'll do it for you.
>
> --
> steve
commit d68b49bae714a7b5881587a61d30d643fa0cdb90
Author: Alessandro Fanfarillo
Date: Thu Nov 26 18:51:47 2015 +0100
New tests for coarray events and new functions in libcaf_single
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index e0b16f5..bcc99ea 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2015-11-26 Tobias Burnus
+Alessandro Fanfarillo
+
+ * gfortran.dg/coarray/event_1.f90: New.
+ * gfortran.dg/coarray/event_2.f90: New.
+
2015-11-25 Markus Trippelsdorf
Paolo Carlini
diff --git a/gcc/testsuite/gfortran.dg/coarray/event_1.f90
b/gcc/testsuite/gfortran.dg/coarray/event_1.f90
new file mode 100644
index 000..b4385f3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/event_1.f90
@@ -0,0 +1,51 @@
+! { dg-do run }
+!
+! Run-time test for EVENT_TYPE
+!
+use iso_fortran_env, only: event_type
+implicit none
+
+type(event_type), save :: var[*]
+integer :: count, stat
+
+count = -42
+call event_query (var, count)
+if (count /= 0) call abort()
+
+stat = 99
+event post (var, stat=stat)
+if (stat /= 0) call abort()
+call event_query(var, count, stat=stat)
+if (count /= 1 .or. stat /= 0) call abort()
+
+stat = 99
+event post (var[this_image()])
+call event_query(var, count)
+if (count /= 2) call abort()
+
+stat = 99
+event wait (var)
+call event_query(var, count)
+if (count /= 1) call abort()
+
+stat = 99
+event post (var)
+call event_query(var, count)
+if (count /= 2) call abort()
+
+stat = 99
+event post (var)
+call event_query(var, count)
+if (count /= 3) call abort()
+
+stat = 99
+event wait (var, until_count=2)
+call event_query(var, count)
+if (count /= 1) call abort()
+
+stat = 99
+event wait (var, stat=stat, until_count=1)
+if (stat /= 0) call abort()
+call event_query(event=var, stat=stat, count=count)
+if (count /= 0 .or. stat /= 0) call abort()
+end
diff --git a/gcc/testsuite/gfortran.dg/coarray/event_2.f90
b/gcc/testsuite/gfortran.dg/coarray/event_2.f90
new file mode 100644
index 000..2d451a5
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/event_2.f90
@@ -0,0 +1,89 @@
+! { dg-do run }
+!
+! Run-time test for EVENT_TYPE
+!
+use iso_fortran_env, only: event_type
+implicit none
+
+type(event_type), save, allocatable :: var(:)[:]
+integer :: count, stat
+
+allocate(var(3)[*])
+
+count = -42
+call event_query (var(1), count)
+if (count /= 0) call abort()
+call event_query (var(1), count)
+if (count /= 0) call abort()
+call event_query (var(2), count)
+if (count /= 0) call abort()
+call event_query (var(3), count)
+if (count /= 0) call abort()
+
+stat = 99
+event post (var(2), stat=stat)
+if (stat /= 0) call abort()
+call event_query (var(1), count)
+if (count /= 0) call abort()
+call event_query(var(2), count, stat=stat)
+if (count /= 1 .or. stat /= 0) call abort()
+call event_query (var(3), count)
+if (count /= 0) call abort()
+
+stat = 99
+event post (var(2)[this_image()])
+call event_query(var(1), count)
+if (count /= 0) call abort()
+call event_query(var(2), count)
+if (count /= 2) call abort()
+call event_query(var(2), count)
+if (count /= 2) call abort()
+call event_query(var(3), count)
+if (count /= 0) call abort()
+
+stat = 99
+event wait (var(2))
+call event_query(var(1), count)
+if (count /= 0) call abort()
+call event_query(var(2), count)
+if (count /= 1) call abort()
+call event_query(var(3), count)
+if (count /= 0) call abort()
+
+stat = 99
+event post (var(2))
+call event_query(var(1), count)
+if (count /= 0) call abort()
+call event_query(var(2), count)
+if (count /= 2) call abort()
+call event_query(var(3), count)
+if (count /= 0) call abort()
+
+stat = 99
+event post (var(2))
+call event_query(var(1), count)
+if (count /= 0) call abort()
+call event_query(var(2), count)
+if (count /= 3) call abort()
+call event_query(var(3), count)
+if (count /= 0) call abort()
+
+stat = 99
+event wait (var(2), until_count=2)
+call event_query(var(1), count)
+if (count /= 0) call abort()
+call event_query(var(2), count)
+if (count /= 1) call abort()
+call event_query(var(3), count)
+if (count /= 0) call abort()
+
+stat = 99
+event wait (var(2), stat=
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo 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. > I have now built and regression tested the patch on x86_64-*-freebsd and i386-*-freebsd. There were no regressions. In reading through the patch, nothing jumped out at me as suspicious/wrong. Tobias, this is OK to commit. If you don't committed by Sunday, I'll do it for you. -- steve
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
> 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 :
> >> 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
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
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
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 :
>> 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
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
> On Nov 25, 2015, at 9:24 AM, Alessandro Fanfarillo > 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. All, As I mentioned previously, WG5 approved the latest TS 18508 document in September and forwarded it to SC22 for approval for publishing so it is essentially final. This is an opportune time to commit the feature. I believe it also puts gfortran in the lead on Fortran 2015 parallel programming support. I don’t think even the Cray compiler supports EVENTs yet. Hopefully this is ok for committing during Stage 3 given that the original version of the patch was submitted by Tobias in April. This feature could have significant, positive impact on parallel performance so it will be exciting to see it hit the trunk. If it gets committed before my next short course, December 7-8, then I’ll incorporate some discussion of EVENTs into the course. Damian
Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
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 :
> 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.
commit 4ebad7d27c29884eb7eed8ddc0628c9b6dc64622
Author: Alessandro Fanfarillo
Date: Wed Nov 25 14:46:07 2015 +0100
ChangeLog update
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 0c81201..3d2c4cf 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,62 @@
+2015-11-25 Tobias Burnus
+ Alessandro Fanfarillo
+
+ * check.c (gfc_check_event_query): New function.
+ * dump-parse-tree.c (show_code_node): Handle EXEC_EVENT_POST,
+ EXEC_EVENT_WAIT.
+ * expr.c (gfc_check_vardef_context): New check for event variables
+ definition.
+ * gfortran.h (gfc_statement): Add ST_EVENT_POST, ST_EVENT_WAIT.
+ (gfc_isym_id): GFC_ISYM_EVENT_QUERY.
+ (struct symbol_attribute): New field.
+ (gfc_exec_op): Add EXEC_EVENT_POST and EXEC_EVENT_WAIT.
+ * gfortran.texi: Document about new events functions and minor
+ changes.
+ * interface.c (compare_parameter): New check.
+ (gfc_procedure_use): New check for explicit procedure interface.
+ (add_subroutines): Add event_query.
+ * intrinsic.h (gfc_check_event_query,gfc_resolve_event_query):
+ New prototypes.
+ * iresolve.c (gfc_resolve_event_query): New function.
+ * iso-fortran-env.def (event_type): New type.
+ * match.c (event_statement,gfc_match_event_post,gfc_match_event_wait):
+ New functions.
+ (gfc_match_name): New event post and event wait.
+ * match.h (gfc_match_event_post,gfc_match_event_wait):
+ New prototypes.
+ * module.c (ab_attribute): Add AB_EVENT_COMP.
+ (attr_bits): Likewise.
+ (mio_symbol_attribute): Handle event_comp attribute.
+ * parse.c (decode_statement): Add ST_EVENT_POST, ST_EVENT_WAIT.
+ (next_statement): Add ST_EVENT_POST, ST_EVENT_WAIT.
+ (gfc_ascii_statement): Add ST_EVENT_POST, ST_EVENT_WAIT.
+ (parse_derived): Check for event_type components.
+ * resolve.c (resolve_allocate_expr): Check for event variable def.
+ (resolve_lock_unlock): Renamed to resolve_lock_unlock_event. It
+ i
[Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
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.
gcc/fortran/check.c | 54 +++
gcc/fortran/dump-parse-tree.c | 27
gcc/fortran/expr.c| 13 ++
gcc/fortran/gfortran.h| 8 +-
gcc/fortran/gfortran.texi | 141 --
gcc/fortran/interface.c | 31 +++-
gcc/fortran/intrinsic.c | 7 +
gcc/fortran/intrinsic.h | 2 +
gcc/fortran/iresolve.c| 8 ++
gcc/fortran/iso-fortran-env.def | 5 +
gcc/fortran/match.c | 199 ++
gcc/fortran/match.h | 2 +
gcc/fortran/module.c | 8 +-
gcc/fortran/parse.c | 69 -
gcc/fortran/resolve.c | 94 ++--
gcc/fortran/st.c | 2 +
gcc/fortran/trans-decl.c | 28 +++-
gcc/fortran/trans-expr.c | 8 +-
gcc/fortran/trans-intrinsic.c | 150 +++
gcc/fortran/trans-stmt.c | 163 +
gcc/fortran/trans-stmt.h | 1 +
gcc/fortran/trans-types.c | 5 +
gcc/fortran/trans.c | 17 ++-
gcc/fortran/trans.h | 7 +-
gcc/testsuite/gfortran.dg/coarray/event_1.f90 | 51 +++
gcc/testsuite/gfortran.dg/coarray/event_2.f90 | 89
26 files changed, 1151 insertions(+), 38 deletions(-)
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index cdb5ff1..d3570b3 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1151,6 +1151,60 @@ gfc_check_atomic_cas (gfc_expr *atom, gfc_expr *old, gfc_expr *compare,
bool
+gfc_check_event_query (gfc_expr *event, gfc_expr *count, gfc_expr *stat)
+{
+ if (event->ts.type != BT_DERIVED
+ || event->ts.u.derived->from_intmod != INTMOD_ISO_FORTRAN_ENV
+ || event->ts.u.derived->intmod_sym_id != ISOFORTRAN_EVENT_TYPE)
+{
+ gfc_error ("EVENT argument at %L to the intrinsic EVENT_QUERY "
+ "shall be of type EVENT_TYPE", &event->where);
+ return false;
+}
+
+ if (!scalar_check (event, 0))
+return false;
+
+ if (!gfc_check_vardef_context (count, false, false, false, NULL))
+{
+ gfc_error ("COUNT argument of the EVENT_QUERY intrinsic function at %L "
+ "shall be definable", &count->whe
