From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from mx2.suse.de (mx2.suse.de [195.135.220.15])
 by sourceware.org (Postfix) with ESMTPS id 233513857C54;
 Mon, 21 Sep 2020 08:11:00 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 233513857C54
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 D1EA1B0D7;
 Mon, 21 Sep 2020 08:11:34 +0000 (UTC)
Date: Mon, 21 Sep 2020 10:10:58 +0200 (CEST)
From: Richard Biener <rguenther@suse.de>
To: Jan Hubicka <hubicka@ucw.cz>
cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org
Subject: Re: New modref/ipa_modref optimization passes
In-Reply-To: <20200921080447.GE6758@kam.mff.cuni.cz>
Message-ID: <nycvar.YFH.7.76.2009211010400.30742@zhemvz.fhfr.qr>
References: <157394261677.27454.2367573047582814412@a285.localdomain>
 <20200919223255.GA69342@kam.mff.cuni.cz>
 <20200920061551.GA29500@kam.mff.cuni.cz>
 <nycvar.YFH.7.76.2009210905150.30742@zhemvz.fhfr.qr>
 <20200921074752.GD91738@kam.mff.cuni.cz>
 <nycvar.YFH.7.76.2009210954580.30742@zhemvz.fhfr.qr>
 <20200921080447.GE6758@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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 08:11:01 -0000

On Mon, 21 Sep 2020, Jan Hubicka wrote:

> > > 
> > > The problem is:
> > > 
> > > alsize (struct array15_unknown & restrict a)
> > > {
> > > ...
> > >   _2 = *a_13(D).dtype.rank;
> > >   _3 = (integer(kind=8)) _2;
> > > ...
> > > }
> > > }
> > > and in main:
> > > 
> > >   struct array02_integer(kind=4) am;
> > >   <bb 6> :
> > >   MEM <c_char[8]> [(struct dtype_type *)&am + 24B] = {};
> > >   am.dtype.elem_len = 4;
> > >   am.dtype.rank = 2;
> > >   am.dtype.type = 1;
> > > ...
> > >   _52 = alsize (&am);
> > > 
> > > Here array15_unknown and array02_integer are different structures with
> > > different canonical types and thus we end up disambiguating the accesses
> > > via base alias sets.
> > > 
> > > My understanding is that this _unknown array descriptor is supposed to
> > > be universal and work with all kinds of arrays.
> > 
> > But the FE builds a new descriptor for each individual call and thus
> > should build a universal descriptor for a call to an universal
> > descriptor argument.
> 
> I see, so you would expect call to alsize to initialize things in
> array15_unkonwn type?  That would work too.

Yes, that's my expectation.  But let's see what fortran folks say.

Richard.