From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22238 invoked by alias); 11 Nov 2015 22:31:27 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22229 invoked by uid 89); 11 Nov 2015 22:31:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 11 Nov 2015 22:31:25 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id CC00B544D18; Wed, 11 Nov 2015 23:31:21 +0100 (CET) Date: Wed, 11 Nov 2015 22:31:00 -0000 From: Jan Hubicka To: Jan Hubicka Cc: Bernd Schmidt , Richard Biener , gcc-patches@gcc.gnu.org Subject: Re: Enable pointer TBAA for LTO Message-ID: <20151111223121.GA88599@kam.mff.cuni.cz> References: <20151108204618.GA68715@kam.mff.cuni.cz> <20151110181515.GB78110@kam.mff.cuni.cz> <564337E7.2070802@redhat.com> <20151111221359.GA93507@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151111221359.GA93507@kam.mff.cuni.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-11/txt/msg01431.txt.bz2 > > On 11/11/2015 10:21 AM, Richard Biener wrote: > > >On Tue, 10 Nov 2015, Jan Hubicka wrote: > > >>The reason is that TYPE_CANONICAL is initialized in get_alias_set that may be > > >>called before we finish all merging and then it is more fine grained than what > > >>we need here (i.e. TYPE_CANONICAL of pointers to two differnt types will be > > >>different, but here we want them to be equal so we can match: > > >> > > >>struct aa { void *ptr;}; > > >>struct bb { int * ptr;}; > > >> > > >>Which is actually required for Fortran interoperability. > > > > Just curious, is this sort of thing documented anywhere? > > See http://www.j3-fortran.org/doc/year/10/10-007.pdf, section 15 (interoperability with C). > It defines that C_PTR is compatible with any C non-function pointer. .. and if you ask about GCC side documentation, I added testcases that should trigger if the Fortran interoperability breaks. I do not think we want to document the above compatibility explicitly, because in future we may want to have more fine grained TBAA for types that are not shared across fortran and C code (= most types in practice) Honza > > Honza > > > > > > Bernd