From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id C0BB9386103A; Tue, 9 Feb 2021 09:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C0BB9386103A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Thomas_Schwinge@mentor.com IronPort-SDR: RH3PbboY7SvlnmPoN1IAwHdMF+sR0Gs8Mpqfd0z160FSMWA3sNAgw3iiA8gKoy9uTYauWQe5q7 h+SkTWMzn5PuvR+/hChhjmA7AZnzmVNfFLmTmSGq7lnBkRaTurYbSlpgc2Y0c/7T69lARQHVZY teF9TTlq8YKXKxEz3MlBFZ1uFxhtPr7xFk9flJi2t5cmLtrFKQbubCepGFbCHg/qtG5laWOLib r5biXTJAypmD8L2pDbH4UsbnYg7J+n9XdxYZ5wYEl/nCmPNYwwgzlrYQHqEBU8ygcT1+CS+pjF J/k= X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="57903426" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 09 Feb 2021 01:45:08 -0800 IronPort-SDR: EO7ICr7/nxeBtHfwt7pSv6oEnHOMYHRJUs240cAjCiHzyJWFkpuCGJuScPRovGOjlQQKWUjPQG LgQJr6neIwPCUC7vlnuijFr1Fyds2584D6Gkio272Z3Y0K88zYecx6AKTKCXOeENqT9JiKHqq6 fm5QT0zMJAuniu5Qxkgm8EYiyyx1Ujmaj5pEOCQjaxZdzLAfgm6APQMLoewne0Vd4v2K/s9ftn d5FGpS8JYmeEtV+OJUSwXhmbICqqF03bY7cSyPlU7ju7zmqBsrA2EHArZgi+gcj52E9b+UJAFd +sk= From: Thomas Schwinge To: Tobias Burnus CC: , , Jakub Jelinek Subject: Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous In-Reply-To: References: User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 9 Feb 2021 10:45:01 +0100 Message-ID: <87wnvhfuci.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 09:45:11 -0000 Hi Tobias! On 2021-02-08T18:50:25+0100, Tobias Burnus wrote: > Found when looking at Julian's 3/4 OpenACC patch, which has not > yet been committed (and needs still to be revised a bit.) > > The fix (a) avoids an ICE when Julian's patch has been applied. > The patch (b) just makes one error message less confusing. > > The testcase shows that only %re/%im run reach the new code as > %kind/%len are !=3D EXPR_VARIABLE. (The error message is slightly > misleading if the 'list item'/'var' is not a variable.) > > > (a) We need to handle REF_INQUIRY gfc_is_simplify_contiguous. > > That function is used for 'is_contiguous(a(:)%re)', but it works > without this patch and simplifies already to .false. > And it is used in openmp.c, which can ICE without this patch. > > (b) Just makes the error message nicer - as only EXPR_VARIABLE > reaches that code, only %re and %im are mentioned in the > error message. As so often, I can't really comment on the Fortran language/GCC Fortran front end details. ;-| > (Actually, it is not completely clear whether %re/%im are invalid > or not; I think they should be =E2=80=93 but one can argue otherwise. > For OpenMP I just saw that it is tacked internally in Issue 2661, > for OpenACC it is tracked as Issue 346 =E2=80=93 but neither has been > discussed, yet.) Thanks for filing/locating these discussion items for OpenACC/OpenMP upstream. May also put these references into the testcases, so that once these get addressed, we have something to 'grep' for in GCC? > PS: '%re'/'%im' permit accessing the real/imaginary part of a > complex variable as lvalue (in the C++ sense) and also permit > "var(:)%re =3D 1.0", which real(z) or imag(z) does not permit. > > var%kind =3D=3D kind(var), but derived types also permit > parameterized derived types (PDT), which can use '%foo' for respective > 'len' and 'kind' components. > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/goacc-gomp/ref_inquiry.f90 Originally, the 'goacc-gomp' testsuites have been meant to be used for testcases related to OpenACC/OpenMP (non-)interoperability, such as improper nesting etc. (should be the only/major use -- given that currently there isn't really any OpenACC/OpenMP interoperability). This one, I'd have put into separate 'gfortran.dg/goacc/ref_inquiry.f90' and 'gfortran.dg/gomp/ref_inquiry.f90' (everyone cross-referencing the other, unless using the same filename makes that obvious enough). > @@ -0,0 +1,42 @@ > +implicit none > +type t > + integer :: i > + character :: c > + complex :: z > +end type t > + > +integer :: i > +character(kind=3D4, len=3D5) :: c > +complex :: z, zz(5) > +type(t) :: x > + > +print *, is_contiguous(zz(:)%re) > + > +! EXPR_VARIABLE / Cf. also OpenMP spec issue 2661 > +!$omp target enter data map(to: z%re) ! { dg-error "Unexpected comple= x-parts designator" } > +!$omp target enter data map(to: z%im) ! { dg-error "Unexpected comple= x-parts designator" } > +!$omp target enter data map(to: x%z%re) ! { dg-error "Unexpected comple= x-parts designator" } > +!$omp target enter data map(to: x%z%im) ! { dg-error "Unexpected comple= x-parts designator" } > + > +! Fails differently as it is not a variable (EXPR_VARIABLE) > +!$omp target enter data map(to: i%kind, c%len) ! { dg-error "not a p= roper array section" } > +!$omp target enter data map(to: x%i%kind, x%c%len) ! { dg-error "not a p= roper array section" } I note that 'zz' variants (see below) are not being checked for OpenMP. > +! Likewise for OpenACC > +!$acc enter data copyin(i%kind, c%len) ! { dg-error "not a proper ar= ray section" } > +!$acc enter data copyin(x%i%kind) ! { dg-error "not a proper ar= ray section" } > +!$acc enter data copyin(x%c%len) ! { dg-error "not a proper ar= ray section" } > +!$acc update self(i%kind, c%len) ! { dg-error "not a proper ar= ray section" } > +!$acc update self(x%i%kind) ! { dg-error "not a proper ar= ray section" } > +!$acc update self(x%c%len) ! { dg-error "not a proper ar= ray section" } > + > +! EXPR_VARIABLE / cf. OpenACC spec issue 346 > +!$acc enter data copyin(z%re) ! { dg-error "Unexpected complex-parts d= esignator" } > +!$acc enter data copyin(z%im) ! { dg-error "Unexpected complex-parts d= esignator" } Need to check that for 'zz', too? (See below.) > +!$acc enter data copyin(x%z%re) ! { dg-error "Unexpected complex-parts d= esignator" } > +!$acc enter data copyin(x%z%im) ! { dg-error "Unexpected complex-parts d= esignator" } > +!$acc update self(z%re) ! { dg-error "Unexpected complex-parts d= esignator" } > +!$acc update self(z%im) ! { dg-error "Unexpected complex-parts d= esignator" } > +!$acc update self(zz%re) > +!$acc update self(zz%im) > +end And for OpenACC, the 'zz' variants do not emit this error message here. (That's not immediately obvious to me.) I can see how data mapping of '[...]%re' etc. are problematic (we're constructing an "incomplete object"?), but 'update' etc. I'd have expected to work: would just copy the respective "part". That, again, is however just my gut feeling, without having done any actual research. Gr=C3=BC=C3=9Fe Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 M=C3=BCnchen R= egistergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: Thomas H= eurung, Frank Th=C3=BCrauf