public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).