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 08E533857C54; Mon, 21 Sep 2020 07:13:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 08E533857C54 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 D88D1ABB2; Mon, 21 Sep 2020 07:14:13 +0000 (UTC) Date: Mon, 21 Sep 2020 09:13:37 +0200 (CEST) From: Richard Biener To: Jan Hubicka cc: =?ISO-8859-2?Q?David_=C8epel=EDk?= , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: New modref/ipa_modref optimization passes In-Reply-To: <20200920061551.GA29500@kam.mff.cuni.cz> Message-ID: References: <157394261677.27454.2367573047582814412@a285.localdomain> <20200919223255.GA69342@kam.mff.cuni.cz> <20200920061551.GA29500@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=-10.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, 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: 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: Mon, 21 Sep 2020 07:13:40 -0000 On Sun, 20 Sep 2020, Jan Hubicka wrote: > Hi, > this is patch I am using to fix the assumed_alias_type.f90 failure by > simply arranging alias set 0 for the problematic array descriptor. There's no such named testcase on trunk. Can you be more specific as to the problem at hand? It looks like gfortran.dg/assumed_type_9.f90 execute FAILs at the moment. In particular how's this not an issue w/o IPA modref? For TYPE(*) I think the object itself cannot be accessed but for arrays the meta-info in the array descriptor can. Now my question would be why the Fortran FE at the call site does not build an appropriately typed array descriptor? CCing the fortran list. > I am not sure this is the best option, but I suppose it is better than > setting all array descritors to have same canonical type (as done by > LTO)? > > Honza > > * trans-types.c (gfc_get_array_type_bounds): Set alias set to 0 for > arrays of unknown element type. > diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c > index 26fdb2803a7..bef3d270c06 100644 > --- a/gcc/fortran/trans-types.c > +++ b/gcc/fortran/trans-types.c > @@ -1903,6 +1903,12 @@ gfc_get_array_type_bounds (tree etype, int dimen, int codimen, tree * lbound, > base_type = gfc_get_array_descriptor_base (dimen, codimen, false); > TYPE_CANONICAL (fat_type) = base_type; > TYPE_STUB_DECL (fat_type) = TYPE_STUB_DECL (base_type); > + /* Arrays of unknown type must alias with all array descriptors. */ > + if (etype == ptr_type_node) > + { > + TYPE_ALIAS_SET (base_type) = 0; > + TYPE_ALIAS_SET (fat_type) = 0; > + } > > tmp = TYPE_NAME (etype); > if (tmp && TREE_CODE (tmp) == TYPE_DECL) > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imend