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
