From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 1FECC3858C78 for ; Wed, 15 Mar 2023 19:36:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1FECC3858C78 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pcWvX-00064s-Uc for gcc-patches@gcc.gnu.org; Wed, 15 Mar 2023 20:36:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331] Date: Wed, 15 Mar 2023 20:36:41 +0100 Message-ID: <89b856a2-5e90-5858-44ae-ba22c8903697@gmx.de> References: <099717a7-2de0-c71a-f9fa-58095e691898@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US In-Reply-To: <099717a7-2de0-c71a-f9fa-58095e691898@codesourcery.com> Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,BODY_8BITS,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20230315193641.joxUNcXk2-FpMNKZTPmIYbVH6amd4uDqoSKDxz9nwDE@z> Hi Tobias, Am 15.03.23 um 10:10 schrieb Tobias Burnus: > Hi Harald, > > On 14.03.23 20:38, Harald Anlauf wrote: >> The testcase covers only non-coarray cases, as playing with >> coarray variants hit pre-exisiting issues in gfortran that >> are very likely unrelated to the interface checks. > I concur (but would not rule out additional interface issues). More testing seems to mostly uncover issues later on in trans*.cc, e.g. when passing type to class. I'll open a PR on this as a followup. >> I consider this rather as post 13-release stuff. > In any case, the coarray issue can be fixed separately. And I think > post-GCC-13 makes sense. Good. >> Regtested on x86_64-pc-linux-gnu.  OK for mainline? > Thanks – LGTM! >> +  formal_as = formal->ts.type == BT_CLASS ? CLASS_DATA (formal)->as >> +                                       : formal->as; >> + > > (Jakub remarks for such code that some editor (emacs?), he does not use, > mis--auto-indent such a code - and proposes to add a parentheses > around the right-hand side of the assignment.) Ah, adding parentheses helps! I've reformatted this block accordingly. Pushed as: https://gcc.gnu.org/g:901edd99b44976b3c2b13a7d525d9e315540186a > * * * > > I also wonder whether we need some run-time testcase. The interface > check now works and I also tend to write dg-do-compile testcases, but > given what can go wrong with all the array descriptor, class etc > handling, we may want to ensure it works at run time. – Thoughts? If you comment out the lines with dg-error, the code compiles and seems to run fine here. I've even found cases where passing array sections works correctly here and with current Intel it does not ;-) I'd prefer to postpone more elaborate run-time tests until we have more non-ICEing related code. Thanks, Harald > (That's independent of the patch it and could be done as follow up, if > it deemed reasonable. The included testcase is surely compile-only as it > has dg-error checks.) > > Tobias > > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 >