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
next prev parent 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).