From: Jakub Jelinek <jakub@redhat.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH V2 0/5] OpenMP: support for imperfectly-nested loops
Date: Tue, 22 Aug 2023 14:56:25 +0200 [thread overview]
Message-ID: <ZOSweZykZtuD1oQx@tucnak> (raw)
In-Reply-To: <20230723221521.3739463-1-sandra@codesourcery.com>
On Sun, Jul 23, 2023 at 04:15:16PM -0600, Sandra Loosemore wrote:
> Here is the latest version of my imperfectly-nested loops patches.
> Compared to the initial version I'd posted in April
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617103.html
>
> this version includes many minor cosmetic fixes suggested by Jakub in
> his initial review (also present in the version I committed to the
> OG13 branch last month), many new test cases to cover various corner
> cases, and code fixes so that C and C++ at least behave consistently
> even if the spec is unclear. The most intrusive of those fixes is
> that I couldn't figure out how to make jumping between different
> structured blocks of intervening code in the same OMP loop construct
> produce errors without introducing new GENERIC and GIMPLE data
> structures to represent a structured block without any other
> associated OpenMP semantics; that's now part 1 of the patch series.
>
> There are a few things from the review comments I haven't done anything
> about:
>
> * I left omp-api.h alone because the Fortran front end needs those
> declarations without everything else in omp-general.h.
Ok.
> * I didn't think I ought to be speculatively implementing extensions
> like allowing "do { ... } while (0);" in intervening code. If it's
> really important for supporting macros, I suppose it will make it
> into a future version of the OpenMP spec.
Ack.
> * I didn't understand the comment about needing to add "#pragma omp
> ordered doacross(source) and sink" to the testcase for errors with
> the "ordered" clause. Isn't that only for cross-iteration
> data dependencies? There aren't any in that loop. Also note that some
> of my new corner-case tests use the "ordered" clause to trigger an
> error to check that things are being correctly parsed as intervening
> code, so if there is something really bogus there that must be fixed,
> it now affects other test cases as well.
ordered(N) clause is meant to be used with doacross loops, where one uses
#pragma omp ordered depend/doacross in the body.
So, when one is testing the rejection of imperfectly nested loops with it,
it is better to actually test it on something properly formed except for the
extra code making the loop imperfectly nested, rather than test it on
something which doesn't have the ordered directives in the body at all.
> * Likewise I didn't know what to do with coming up with a better
> testcase for "scan". I could not find an existing testcase with nested
> loops that I could just add intervening code to, and when I made
What about libgomp.c-c++-common/scan-1.c ?
Obviously, you can cut the initialization and checking, because that is a
runtime testcase and all you need is a compile time test; perhaps put each
of the 2 loop nests into a separate function and just add some code in
between the loops + dg-error.
Jakub
prev parent reply other threads:[~2023-08-22 12:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-23 22:15 Sandra Loosemore
2023-07-23 22:15 ` [PATCH V2 1/5] OpenMP: Add OMP_STRUCTURED_BLOCK and GIMPLE_OMP_STRUCTURED_BLOCK Sandra Loosemore
2023-08-22 13:01 ` Jakub Jelinek
2023-07-23 22:15 ` [PATCH V2 2/5] OpenMP: C front end support for imperfectly-nested loops Sandra Loosemore
2023-08-22 13:23 ` Jakub Jelinek
2023-08-22 18:53 ` Sandra Loosemore
2023-08-24 11:49 ` Jakub Jelinek
2023-07-23 22:15 ` [PATCH V2 3/5] OpenMP: C++ " Sandra Loosemore
2023-08-22 13:31 ` Jakub Jelinek
2023-07-23 22:15 ` [PATCH V2 4/5] OpenMP: New C/C++ testcases for imperfectly nested loops Sandra Loosemore
2023-08-22 13:34 ` Jakub Jelinek
2023-07-23 22:15 ` [PATCH V2 5/5] OpenMP: Fortran support for imperfectly-nested loops Sandra Loosemore
2023-08-22 13:37 ` Jakub Jelinek
2023-08-24 16:36 ` Tobias Burnus
2023-08-22 12:56 ` Jakub Jelinek [this message]
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=ZOSweZykZtuD1oQx@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=sandra@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).