From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 36AAF385042E; Tue, 27 Jul 2021 11:07:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 36AAF385042E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: ie0tI8Gz5gHS8xyxKbgjRPhiRSnZIPpIZcxtn1BZtyUA/7hj9mSI4zupUD7Y0lEJt/Po+Lp5Yq WpD+cZJGw+96tu+fbtUef1wUATCuJDJrxRbNuWaQ0B+27DLBxmlQuqWuKa1MLsT5+kvDmRuzdA Nr7JYsnLUJtjdBBSLFNbL0UT5OoVDsB2TlMfrCJDoDD7CzODU68LtAgDdrDgq/Fh9hD+ZHP6J0 69qvL3wLLe6E8weeXTPMA7N8dD/szFP3aUzgVZI7AJyjecRvf+gII6FiCDdUdwwQadPrKwkinV Tdy4msC2tPuFlL7fwSlvwREl X-IronPort-AV: E=Sophos;i="5.84,273,1620720000"; d="scan'208";a="63951990" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 27 Jul 2021 03:07:09 -0800 IronPort-SDR: OPAfliflHuj3EUALDxZSMGYecKV3SFI3kwbAx4v9bsWIMGx48af9dx7mQOzc3AybFdAsRnkQy3 v5xJUtPSMlumgzfTv4tv2geiEgHlO13B8J/tsnNAIG05eTY+b+CZVj1twJTbmyRAoaEDwnz9Yq +WVfW6SQgKrLw7nHdKyDPdtsZjsQthocjzFlhjl5ppnJt9COIxt81jvTqHOvi+LP5uspf9Mz35 OTn8r9v0+u4+g/I/NWcmdVFOmVpia8Udw/XLQjyNphIKT3vGMOpbj7lYRifPKn5qTLFsh/0QwR P5c= Subject: Re: [PATCH v2, Fortran] TS 29113 testsuite To: Sandra Loosemore , "gcc-patches@gcc.gnu.org" , "fortran@gcc.gnu.org" , Thomas Koenig CC: =?UTF-8?Q?Jos=c3=a9_Rui_Faustino_de_Sousa?= References: <64135fb4-c218-4026-6166-5018f11ebfe0@codesourcery.com> <84cbe3c1-b9db-a4ae-649f-c426448f8bcc@codesourcery.com> From: Tobias Burnus Message-ID: <47e5cae8-1d71-4017-0978-96670a773ad0@codesourcery.com> Date: Tue, 27 Jul 2021 13:07:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <84cbe3c1-b9db-a4ae-649f-c426448f8bcc@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 27 Jul 2021 11:07:12 -0000 Hi Sandra, hi Thomas, hi all, @Thomas K: Comments about the following - and of course to the testsuite itself - are highly welcome. In my opinion, the testsuite LGTM and can be committed. @Sandra: - Thoughts on the directory name? (cf. below) - Give others/Thomas a chance to comment on this, before committing it. (And remove the now passing xfails.) Thanks for the testsuite! Regarding: * XFAILS - as discussed before, I think having some XFAILS is not ideal but fine, especially if the XFAIL/PASS ratio is low and there are plans to fix the known fails, some posted patches for those, and open PRs for the issues. (I think there is one patch pending review and two patches pending committal with some modifications by Sandra - plus several patches by Jos=C3=A9 which still need to be reviewed.) * Naming of the directory + .exp file: ts29113/ts29113.exp is okay. Given that 'select rank' (in F2018 but not in TS29113) is also tested, there was some controversy regarding the name and the coverage; additionally, TS29113 is a name which is not immediately clear. Thus, we could use some other name like: c-interop/c-interop.exp or .... (suggestions?). In any case, I do not feel strong about either name. * I had a closer look at earlier versions of the testsuite, I did browse through the current one + looked at the diff to previous version, but it is big enough and the spec is complex enough that I have likely missed something. Thus: Additional reviews are highly welcome! Other than that: On 25.07.21 21:47, Sandra Loosemore wrote: > Here is an updated version of my TS29113 testsuite. ... > And this approved but not-yet-committed patch from Jose > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572725.html > fixes 6 more. The patch was committed as r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d040= 4c [see also PR fortran/101635 for an open issue]: I can confirm that gfortran.dg/ts29113/interoperability/cf-descriptor-2.f90 now shows XPASS (6 times for -m64, 6 times for -m32). Overall, I see (x86-64-gnu-linux): =3D=3D=3D gfortran Summary for unix =3D=3D=3D # of expected passes 1041 # of unexpected successes 6 # of expected failures 269 # of unresolved testcases 30 =3D=3D=3D gfortran Summary for unix/-m32 =3D=3D=3D # of expected passes 1029 # of unexpected successes 6 # of expected failures 257 # of unresolved testcases 30 # of unsupported tests 12 Unexpected success -> see XPASS above Unsupported =3D dg-require-effective-target, unsupported for -m32. Unresolved =3D dg-do run, but failed to compile * * * Regarding: gfortran.dg/ts29113/interoperability/contiguous-2.f90 ! FIXME: is this correct? "the Fortran processor will handle the ! difference in contiguity" may not mean that it's required to make ! the array contiguous, just that it can access it correctly? I think the latter is permitted - and makes sense when the contiguity is not needed. For instance, arg =3D 5 ! -> implicit loop + array-element access does not require a contiguous array, even though assuming sm =3D sizeof(ele= m) might generate faster code, e.g. by permitting vector ops. And for size(arg) it does not really matter whether 'arg' is contiguous or not. But for any call which needs a contiguous argument, contiguity is required - which then implies that the compiler has to make the argument contiguous (copy into a contiguous temporary). The simplest is to always do the copy-in-into-temp (when not contiguous), but of course there is room for optimization - like always. In terms of the testsuite, I think the test as written is fine: if later more optimizations are done in GCC, the GCC developer can still inspect the FAIL, read your comment, and modify the testcase accordingly. Thanks, Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955