public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Nathan Weeks <weeks@iastate.edu>
Cc: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH,Fortran][RFC] PR 87939, 87326 - STAT= and ERRMSG= specifiers in several image control statements; NEW_INDEX= specifier in FORM TEAM statement
Date: Thu, 17 Jan 2019 02:07:00 -0000	[thread overview]
Message-ID: <20190117020656.GA52290@troutmask.apl.washington.edu> (raw)
In-Reply-To: <CAHSgV3HbAEDZUHvCkZ3S0LcsK+NhkuvqypBLJwZHgoCL36nNaQ@mail.gmail.com>

Nathan,

Thanks for taking an interesting in improving gfortran.  A
scan of the bug database certainly suggests we can use the
help particularly with coarray bugs.  Before we can go much
further, do you have a copyright assignment on file the FSF.
If not, please see https://gcc.gnu.org/contribute.html

-- 
steve

On Wed, Jan 16, 2019 at 06:16:12PM -0600, Nathan Weeks wrote:
> Hi all,
> 
> To facilitate more complete Fortran 2018 failed images support, I'm
> particularly interested in interested in seeing PR 87939 eventually
> resolved (i.e., allow STAT= and ERRMSG= specifiers in FORM TEAM,
> CHANGE TEAM, SYNC TEAM, END TEAM, and CRITICAL statements). To get the
> ball rolling (I realize that the boat has been missed for this kind of
> change in GCC 9 trunk), I've attempted the following patch (which,
> since it was convenient to do while modifying FORM TEAM-related code,
> also adds the NEW_INDEX= specifier to the FORM TEAM statement as
> desired in PR 87326).
> 
> This is the first gfortran patch I've attempted, and I certainly could
> have made some noob mistakes, so verbose feedback would be
> appreciated.
> 
> A few comments:
> 
> * In resolve.c, the newly-added functions that type check STAT= and
> ERRMSG= arguments for FORM TEAM, CHANGE TEAM, and SYNC TEAM also add
> (previously-absent) type checking for their TEAM_TYPE arguments. If
> it's more appropriate, I could separate this change into its own PR.
> 
> * The existing -fcoarray=lib implementation of CRITICAL acquires a
> LOCK on a lock variable on image 1 (in the current team). However, a
> CRITICAL statement stat-value of STAT_FAILED_IMAGE (i.e., the image
> that enter the CRITICAL construct failed) is analogous to the LOCK
> stat-value of STAT_UNLOCKED_FAILED_IMAGE (i.e., the image that
> acquired the lock failed---see section 11.6.11 (7 & 10) in Fortran
> 2018 draft N2146), whereas a LOCK STAT_FAILED_IMAGE means the image on
> which the lock variable resides has failed (no analog in the CRITICAL
> statement, which is oblivious to this underlying implementation). So
> in addition to adding the stat value STAT_UNLOCKED_FAILED_IMAGE to
> libgfortran.h & libcaf.h, I had CRITICAL swap a LOCK
> STAT_UNLOCKED_FAILED_IMAGE for STAT_FAILED_IMAGE, and (perhaps
> unimaginatively) a LOCK STAT_FAILED_IMAGE for
> STAT_UNLOCKED_FAILED_IMAGE (which, while it has no defined meaning for
> a CRITICAL statement, fits the definition of a "processor-dependent
> value other than STAT_FAILED_IMAGE").
> 
> * A couple negative tests for syntax errors (coarray_critical_2.f90 &
> team_end_2.f90) fail due to spurious "Error: Expecting END PROGRAM
> statement at (1)" errors that are also emitted by gfortran 8.2.0 as
> well.
> 
> Thanks,
> 
> --
> Nathan
> 
> frontend:
> 
> 2019-01-16  Nathan Weeks  <weeks@iastate.edu>
> 
>         PR fortran/87939
>         PR fortran/87326
>         * gfortran.h: Add an additional gfc_expr member to struct gfc_code.
>         * libcaf.h: Add support for STAT_UNLOCKED_FAILED_IMAGE.
>         * match.c (gfc_match_critical): Add STAT= and ERRMSG=.
>         (gfc_match_change_team): Likewise.
>         (gfc_match_end_team): Likewise.
>         (gfc_match_sync_team): Likewise.
>         (gfc_match_form_team): Add STAT=, ERRMSG=, and NEW_INDEX=.
>         * resolve.c (resolve_form_team): New. Type check team-variable
> argument in
>         addition to new STAT= and ERRMSG= arguments.
>         (resolve_change_sync_team): New. Adds type checking for team-value
>         argument.
>         (resolve_end_team): New.
>         (resolve_critical): Add STAT= and ERRMSG=.
>         * trans-decl.c (gfc_build_builtin_function_decls): Additional stat,
>         errmsg, and errmsg_len arguments to _gfortran_caf_form_team(),
>         _gfortran_caf_change_team(), _gfortran_caf_end_team(), and
>         _gfortran_caf_sync_team(), and additional new_index argument to
>         _gfortran_caf_form_team().
>         * trans-stmt.c (gfc_trans_form_team): Support STAT=, ERRMSG=, and
>         NEW_INDEX=.
>         (gfc_trans_change_team): Support STAT= and ERRMSG=.
>         (gfc_trans_end_team): Likewise.
>         (gfc_trans_sync_team): Likewise.
>         (gfc_trans_critical): Likewise. Also support assigning STAT_FAILED_IMAGE
>         to a stat-variable.
> 
> libgfortran:
> 
> 2019-01-16  Nathan Weeks  <weeks@iastate.edu>
> 
>         PR fortran/87939
>         * libgfortran.h: Add support for STAT_UNLOCKED_FAILED_IMAGE
> 
> testsuite:
> 
> 2019-01-16  Nathan Weeks  <weeks@iastate.edu>
> 
>         PR fortran/87939
>         PR fortran/87326
>         * gfortran.dg/coarray_critical_2.f90: New test
>         * gfortran.dg/coarray_critical_3.f90: New test
>         * gfortran.dg/coarray_critical_4.f90: New test
>         * gfortran.dg/team_change_2.f90: New test
>         * gfortran.dg/team_change_3.f90: New test
>         * gfortran.dg/team_end_2.f90: New test
>         * gfortran.dg/team_end_3.f90: New test
>         * gfortran.dg/team_form_2.f90: New test
>         * gfortran.dg/team_form_3.f90: New test
>         * gfortran.dg/team_sync_1.f90: New test
>         * gfortran.dg/team_sync_2.f90: New test



-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

  reply	other threads:[~2019-01-17  2:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17  0:16 Nathan Weeks
2019-01-17  2:07 ` Steve Kargl [this message]
2019-01-17 15:08   ` Nathan Weeks
2019-01-18 19:17 ` Nathan Weeks
2019-01-18 19:27   ` Steve Kargl
2019-01-18 20:01     ` Nathan Weeks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190117020656.GA52290@troutmask.apl.washington.edu \
    --to=sgk@troutmask.apl.washington.edu \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=weeks@iastate.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).