From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110109 invoked by alias); 5 Feb 2018 10:17:45 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 109816 invoked by uid 89); 5 Feb 2018 10:17:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=embed X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Feb 2018 10:17:42 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 71FE8AAB6; Mon, 5 Feb 2018 10:17:39 +0000 (UTC) Date: Mon, 05 Feb 2018 10:17:00 -0000 From: Richard Biener To: Jakub Jelinek cc: Thomas Koenig , "fortran@gcc.gnu.org" Subject: Re: Fortran LTO and array descriptors. In-Reply-To: <20180203173119.GB28993@laptop.zalov.cz> Message-ID: References: <5f4d68c5-9237-3bde-b175-389cca9150fc@netcologne.de> <20180203173119.GB28993@laptop.zalov.cz> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2018-02/txt/msg00023.txt.bz2 On Sat, 3 Feb 2018, Jakub Jelinek wrote: > On Sat, Feb 03, 2018 at 06:09:41PM +0100, Thomas Koenig wrote: > > I have been looking at PR 68649 and 68717. They are the > > same bug, really (and there are quite a few more). > > > > Jakub has written a good analysis of the problem at > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649#c12 . > > > > To sum it up, we create different types for each rank of > > array, and then call the library. When we call the > > same function with different ranks, lto complains, with > > good reason. > > > > The last comment, by Richard, ends with the rather > > pessimistic "Thus even the proposed fix won't end up working." > > > > This problem prevents users from a lot of LTO use cases. It also > > prevents us from using LTO with the library (although I > > strongly suspect that there are also other stumbling blocks). > > > > So, what to do? On the libfortran side, I tried out the patch > > Trying Richi's testcase with real flexible array member doesn't help: > struct Xflex > { > int n; > int a[]; > }; > struct Xspecific > { > int n; > int a[7]; > } x; > > int > foo (struct Xflex *f) > { > f->a[6] = 2; > x.a[6] = 1; > return f->a[6]; > } > > still returns 2 at -O2. What seems to work is: > struct Xflex > { > int n; > int a[]; > }; > union Uspecific > { > struct Xflex flex; > struct Xspecific > { > int n; > int a[7]; > } specific; > } x; > > int > foo (struct Xflex *f) > { > f->a[6] = 2; > x.specific.a[6] = 1; > return f->a[6]; > } > > i.e. have a generic struct with flexible array member, which is what e.g. > the libgfortran APIs take as arguments, and when you actually need an object > on the stack or static object, make it a union of that generic struct with > flexible array member and the struct specific for how big rank you want. > > I can try to implement that next week if that's what we agree on. Note given you control what IL is presented to GCC in the Fortran FE you don't need to jump through hoops using a union -- you can rely on the middle-end behavior and simply emit code as if you'd write in C: ((struct Xflex *)&x)->a[6] = 1; or in GENERIC terms you wrap the Xspecific objects in a MEM_REF with operand 1 being build_int_cst (pointer_to_Xflex_type_node, 0) which tells GCC to use the alias-set of Xflex. So wherever you build "decls" of one of the array-descriptor types (or embed them into a struct!) when you access the descriptor use the trailing-array variant. I think I've seen all array descriptor accesses code-generation abstracted away in some helper routines. Richard.