From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id CE97E386F461; Fri, 16 Oct 2020 09:20:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CE97E386F461 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rguenther@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 99331AEA2; Fri, 16 Oct 2020 09:20:23 +0000 (UTC) Date: Fri, 16 Oct 2020 11:20:23 +0200 (CEST) From: Richard Biener Sender: rguenther@c653.arch.suse.de To: Jan Hubicka cc: Tobias Burnus , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: New modref/ipa_modref optimization passes In-Reply-To: Message-ID: References: <157394261677.27454.2367573047582814412@a285.localdomain> <20200919223255.GA69342@kam.mff.cuni.cz> <20200920061551.GA29500@kam.mff.cuni.cz> <20200921074752.GD91738@kam.mff.cuni.cz> <20200921080447.GE6758@kam.mff.cuni.cz> <7ed1450c-68e1-a61a-307f-f07a474225e9@net-b.de> <20200927213740.GA52458@kam.mff.cuni.cz> <20201016075614.GA94042@kam.mff.cuni.cz> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 09:20:26 -0000 On Fri, 16 Oct 2020, Richard Biener wrote: > On Fri, 16 Oct 2020, Jan Hubicka wrote: > > > Hi, > > I am slowly getting finished with the fn spec changes on trunk and then > > would like to proceed with modref. Sadly still get the assumed_type > > failuere and in addition to that: > > FAIL: gfortran.dg/finalize_25.f90 -O2 execution test > > FAIL: gfortran.dg/finalize_25.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test > > FAIL: gfortran.dg/finalize_25.f90 -O3 -g execution test > > FAIL: gfortran.dg/finalize_25.f90 -Os execution test > > WARNING: gfortran.dg/pdt_14.f03 -O2 execution test program timed out. > > FAIL: gfortran.dg/pdt_14.f03 -O2 execution test > > WARNING: gfortran.dg/pdt_14.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test > > program timed out. > > FAIL: gfortran.dg/pdt_14.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test > > WARNING: gfortran.dg/pdt_14.f03 -O3 -g execution test program timed out. > > FAIL: gfortran.dg/pdt_14.f03 -O3 -g execution test > > WARNING: gfortran.dg/pdt_14.f03 -Os execution test program timed out. > > FAIL: gfortran.dg/pdt_14.f03 -Os execution test > > > > I wonder if there is any chance to get Fortran FE fixed here? > > OK, I'll try doing a little surgery in the FE today, coming up with > a little refactoring and a fix along your original one that allows > for a better one by FE folks. So I've sent a refactoring patch improving the tree building code. But now trying to fix the actual issue with the idea to perform accesses indirectly via a descriptor with dim[] type I see that the coarray 'token' field is appended to descriptors conditional on -fcoarray and that this field makes the dim[] array no longer trailing - which means the offset of the 'token' field depends on the rank of the array. The dim[] field is even optional when dim + codimen == 0 and that case indeed happens (ah, via get_scalar_to_descriptor_type). So much for re-using this combo ;) I suppose we can compensate for this by dynamically computing the offset of the 'token' field but then it's not obvious to me where the total 'rank' is stored inside the descriptor or how the 'token' field is accessed for assumed-shape arrays - the current method by simple field chaining definitely won't work. Anyway, I'll try to deal with all this by just adjusting the TBAA type but not the access type leaving that alone. IMHO the cleanest way would be to swap the CAF token field and the dim[] field (which is an ABI change for -fcoarray) Richard.