From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 469E03858D28 for ; Tue, 22 Aug 2023 12:56:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 469E03858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692708989; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=8Gjkmhz2kKKM9lG5vyfDGJLKwgUGfilII6P2OJI2vz8=; b=hfJ3VFd7r6U4gou8bawH6bpAqmuJTZUnwZQcL5UqswE0gUhmVQ+gOPmZV2uqSOFum3YIex 4XK7gE3dXJU3vea48tdfCvB73Xtb8lrxGAMM4BPbZQaIsPwZ3jADnzCAPMPlZuISKtkYn+ tGv/vEptGiJhPy41odPbu4hdOtmV3L0= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-182-0zHZABuJNF2khIZjihmKrw-1; Tue, 22 Aug 2023 08:56:28 -0400 X-MC-Unique: 0zHZABuJNF2khIZjihmKrw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C9F08381C169; Tue, 22 Aug 2023 12:56:27 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.165]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 900A240D2843; Tue, 22 Aug 2023 12:56:27 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 37MCuPFY2437816 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 22 Aug 2023 14:56:25 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 37MCuPp12437813; Tue, 22 Aug 2023 14:56:25 +0200 Date: Tue, 22 Aug 2023 14:56:25 +0200 From: Jakub Jelinek To: Sandra Loosemore Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH V2 0/5] OpenMP: support for imperfectly-nested loops Message-ID: Reply-To: Jakub Jelinek References: <20230723221521.3739463-1-sandra@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <20230723221521.3739463-1-sandra@codesourcery.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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