From: Jakub Jelinek <jakub@redhat.com>
To: Nathan Sidwell <nathan@acm.org>
Cc: Thomas Schwinge <thomas@codesourcery.com>,
Joseph Myers <joseph@codesourcery.com>,
James Norris <jnorris@codesourcery.com>,
Cesar Philippidis <cesar@codesourcery.com>,
gcc-patches@gcc.gnu.org, Jason Merrill <jason@redhat.com>
Subject: Re: [PR c/64765, c/64880] Support OpenACC Combined Directives in C, C++
Date: Fri, 09 Oct 2015 13:57:00 -0000 [thread overview]
Message-ID: <20151009135740.GI8714@tucnak.redhat.com> (raw)
In-Reply-To: <5617C27B.9040706@acm.org>
On Fri, Oct 09, 2015 at 09:34:51AM -0400, Nathan Sidwell wrote:
> On 10/09/15 09:26, Thomas Schwinge wrote:
> >Hi!
>
> >You mean the cp_parser_oacc_loop and cp_parser_oacc_kernels_parallel
> >functions need documentation? I agree it's a bit terse, but documenting
> >these by just listing the accepted parsing tokens "# pragma acc loop"
> >etc., followed by the *_CLAUSE_MASKs is what's done for the other
> >OpenACC/OpenMP directives in the C/C++ front ends. So, I don't see a
> >reason to be different for these two?
>
>
> What's the p_name argument for?
That is a pointer to the name of the combined/composite construct.
This stuff works basically that if you have a combined construct,
you call the outermost parsing routine with a buffer long enough to
contain the longest possible combined construct name, and
strcpy (p_name, "#pragma omp {omp,acc}");
first, and then each parsing routine strcats the name of itself
after that (and merges in its own clause mask), and finally on
the innermost construct you have the full name of your combined construct in
p_name and the right clause mask in mask, so you call the clause
parsing with those two parameters, which might use the name
for diagnostics.
Jakub
next prev parent reply other threads:[~2015-10-09 13:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-08 16:39 Thomas Schwinge
2015-10-08 16:47 ` Joseph Myers
2015-10-09 12:26 ` Nathan Sidwell
2015-10-09 13:26 ` Thomas Schwinge
2015-10-09 13:34 ` Nathan Sidwell
2015-10-09 13:57 ` Jakub Jelinek [this message]
2015-10-09 14:00 ` Thomas Schwinge
2015-10-11 22:19 ` Nathan Sidwell
2015-10-27 8:52 ` Thomas Schwinge
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=20151009135740.GI8714@tucnak.redhat.com \
--to=jakub@redhat.com \
--cc=cesar@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=jnorris@codesourcery.com \
--cc=joseph@codesourcery.com \
--cc=nathan@acm.org \
--cc=thomas@codesourcery.com \
/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).