public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Cesar Philippidis <cesar@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, Fortran List <fortran@gcc.gnu.org>
Subject: Re: OpenACC wait clause
Date: Fri, 24 Jun 2016 15:53:00 -0000	[thread overview]
Message-ID: <20160624155322.GD7387@tucnak.redhat.com> (raw)
In-Reply-To: <576D54F9.9030008@codesourcery.com>

On Fri, Jun 24, 2016 at 08:42:49AM -0700, Cesar Philippidis wrote:
> >> @@ -1328,7 +1328,8 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, uint64_t mask,
> >>  	      && gfc_match ("wait") == MATCH_YES)
> >>  	    {
> >>  	      c->wait = true;
> >> -	      match_oacc_expr_list (" (", &c->wait_list, false);
> >> +	      if (match_oacc_expr_list (" (", &c->wait_list, false) == MATCH_NO)
> >> +		needs_space = true;
> >>  	      continue;
> >>  	    }
> >>  	  if ((mask & OMP_CLAUSE_WORKER)
> > 
> > I think it is still problematic.  Most of the parsing fortran FE errors are deferred,
> > meaning that if you don't reject the whole gfc_match_omp_clauses, then no
> > diagnostics is actually emitted.
> 
> What exactly is the problem here? Do you want more precise errors or do
> you want to keep the errors generic and deferred?

The problem is that if you ignore MATCH_ERROR and don't reject the stmt,
then invalid source will be accepted, which is not acceptable.

I admit the Fortran OpenMP/OpenACC error recovery and diagnostics is not
very good, but it generally follows the model done elsewhere in the Fortran
FE.  So, I think before changing anything substantial first the bugs in
there (where MATCH_ERROR is ignored) should be fixed (something that can be
also backported), and only afterwards we should be discussing some plan to
improve the infrastructure (like for clauses if there are any non-fatal
errors in the parsing emit the diagnostics immediately, don't add the
clauses to the FE IL and don't reject the whole stmt).

	Jakub

  reply	other threads:[~2016-06-24 15:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160607111307.GQ7387@tucnak.redhat.com>
     [not found] ` <5756E1B6.605@codesourcery.com>
     [not found]   ` <20160607150252.GS7387@tucnak.redhat.com>
2016-06-17  3:22     ` Cesar Philippidis
2016-06-17 14:34       ` Jakub Jelinek
2016-06-24 15:42         ` Cesar Philippidis
2016-06-24 15:53           ` Jakub Jelinek [this message]
2016-06-27 18:36             ` Cesar Philippidis
2016-06-27 19:23               ` Jakub Jelinek
2016-06-27 23:22                 ` Cesar Philippidis
2016-06-28  7:08                   ` Jakub Jelinek

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=20160624155322.GD7387@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=cesar@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /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).