Message ID | CAHqFgjVtwTSsOtcTT+BedhzWeDBo4EZp7uLPHKz=PBQjTgH5HA@mail.gmail.com |
---|---|
State | New |
Headers | show |
> On Nov 25, 2015, at 9:24 AM, 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. 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
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.
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.
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.
*PING* 2015-11-26 17:51 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>: > 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
Committed as revision 231208. Alessandro, Tobias, is this a candidate for a commit to the 5-branch when it is re-opened?
Yes please. Thanks. 2015-12-02 23:00 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>: > 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 <sgk@troutmask.apl.washington.edu>: >> > 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
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 <sgk@troutmask.apl.washington.edu>: > 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 <sgk@troutmask.apl.washington.edu>: >> > 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
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.
Great! Thanks. 2015-12-17 15:57 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>: > 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
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 <burnus@net-b.de> + Alessandro Fanfarillo <fanfarillo.gcc@gmail.com> + + * 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 + includes logic for locks and events. + (gfc_resolve_code): Call it. + (gfc_resolve_symbol): New check for event variable to be a corray. + * st.c (gfc_free_statement): Handle new EXEC_EVENT_POST and + EXEC_EVENT_WAIT. + * trans-decl.c (gfor_fndecl_caf_event_post,gfor_fndecl_caf_event_wait, + gfor_fndecl_caf_event_query): New global variables. + (generate_coarray_sym_init): Checking for event_type. + (gfc_conv_procedure_call): Check for C bind attribute. + * trans-intrinsic.c (conv_intrinsic_event_query): New function. + (conv_intrinsic_move_alloc): Call it. + * trans-stmt.c (gfc_trans_lock_unlock): Passing address + of actual argument. + (gfc_trans_sync): Likewise. + (gfc_trans_event_post_wait): New function. + * trans-stmt.h (gfc_trans_event_post_wait): New prototype. + * trans-types.c (gfc_get_derived_type): Integer_kind as event_type. + * trans.c (gfc_allocate_using_lib): New argument and logic for events. + (gfc_allocate_allocatable): Passing new argument. + (trans_code): Handle EXEC_EVENT_POST, EXEC_EVENT_WAIT. + * trans.h (gfc_coarray_type): New elements. + (gfor_fndecl_caf_event_post,gfor_fndecl_caf_event_wait, + gfor_fndecl_caf_event_query): Declare them. + 2015-11-22 Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/68486