From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by sourceware.org (Postfix) with ESMTPS id CB3403858C83 for ; Tue, 26 Apr 2022 17:12:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB3403858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.253.179.215]) by smtp.orange.fr with ESMTPA id jOjVnSwYMZLw1jOjan002a; Tue, 26 Apr 2022 19:12:19 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Tue, 26 Apr 2022 19:12:19 +0200 X-ME-IP: 86.253.179.215 Message-ID: <737d7a95-33f0-4264-4ba7-caed687c3092@orange.fr> Date: Tue, 26 Apr 2022 19:12:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH] fortran: Avoid infinite self-recursion [PR105381] Content-Language: en-US To: Jakub Jelinek , Tobias Burnus Cc: gfortran , gcc-patches , Harald Anlauf References: <8f082ce4-a6a9-72c1-a882-4663426adaff@orange.fr> <4567d0f0-3077-d582-e2d2-b0169c322009@codesourcery.com> From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, FREEMAIL_FROM, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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, 26 Apr 2022 17:12:22 -0000 Le 26/04/2022 à 15:32, Jakub Jelinek a écrit : > On Tue, Apr 26, 2022 at 03:22:08PM +0200, Tobias Burnus wrote: >> LGTM - however: >> >> On 26.04.22 14:38, Mikael Morin wrote: >>> --- a/gcc/fortran/trans-array.cc >>> +++ b/gcc/fortran/trans-array.cc >>> @@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr) >>> if (DECL_P (expr) >>> && DECL_LANG_SPECIFIC (expr)) >>> if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr)) >>> - return non_negative_strides_array_p (orig_decl); >>> + if (orig_decl != expr) >>> + return non_negative_strides_array_p (orig_decl); >> >> Is the if()if()if() cascade really needed? I can see a reason that an >> extra 'if' is preferred for the variable declaration of orig_decl, but >> can't we at least put the new 'orig_decl != expr' with an '&&' into the >> same if as the decl/in the second if? Besides clearer, it also avoids >> further identing the return line. > > I think we can't in C++11/C++14. The options can be if orig_decl would be declared > earlier, then it can be > tree orig_decl; > if (DECL_P (expr) > && DECL_LANG_SPECIFIC (expr) > && (orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr)) > && orig_decl != expr) > return non_negative_strides_array_p (orig_decl); > but I think this is generally frowned upon, > or one can repeat it like: > if (DECL_P (expr) > && DECL_LANG_SPECIFIC (expr) > && GFC_DECL_SAVED_DESCRIPTOR (expr) > && GFC_DECL_SAVED_DESCRIPTOR (expr) != expr) > return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (expr)); I think I’ll use that. There are numerous places where macros are repeated like this already and everybody seems to be pleased with it. Thanks for the feedback, and for the suggestions. > or what Mikael wrote, perhaps with the && on one line: > if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr)) > if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr)) > if (orig_decl != expr) > return non_negative_strides_array_p (orig_decl); > In C++17 and later one can write: > if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr)) > if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr); > orig_decl && orig_decl != expr) > return non_negative_strides_array_p (orig_decl); > > Jakub >