From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21390 invoked by alias); 29 May 2019 13:31:33 -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 21335 invoked by uid 89); 29 May 2019 13:31:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1 autolearn=ham version=3.3.1 spammy= 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 ESMTP; Wed, 29 May 2019 13:31:30 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 7AEFB2804ED; Wed, 29 May 2019 15:31:22 +0200 (CEST) Date: Wed, 29 May 2019 13:32:00 -0000 From: Jan Hubicka To: Richard Biener Cc: gcc-patches@gcc.gnu.org, d@dcepelik.cz Subject: Re: Teach same_types_for_tbaa to structurally compare arrays, pointers and vectors Message-ID: <20190529133122.gihyzhf5yps35mdg@kam.mff.cuni.cz> References: <20190524111433.mv5z33ysiatlxmxz@kam.mff.cuni.cz> <20190524131856.zduvz27dbjfy6yqw@kam.mff.cuni.cz> <20190527135458.imf4ek2kd7qwefxy@kam.mff.cuni.cz> <20190529123353.kfsfisrm5mkzm6rv@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2019-05/txt/msg01902.txt.bz2 > > /* ??? Array types are not properly unified in all cases as we have > > spurious changes in the index types for example. Removing this > > causes all sorts of problems with the Fortran frontend. */ > > if (TREE_CODE (type1) == ARRAY_TYPE > > && TREE_CODE (type2) == ARRAY_TYPE) > > return -1; > > > > And it causes no regressions. I looked for the history and see you > > added it in 2009 because Fortran mixes up array of chars with char > > itself. I am not sure if that was fixed since then or it is just > > about missing testcase? > > I think we had a testcase back then and I'm not aware of any fixes > here. The introducing mail says we miscompile protein (part of > polyhedron). Another thing about arrays is that unification > doesn't work for VLAs even in C (consider nested fns being > inlined and sharing an array type with the caller), so we cannot > really say ARRAY_TYPEs with non-constant bounds are ever > "not equal". So simply dropping this check looks wrong. > I'm not sure about char[] vs char but the FE definitely can > end up with char vs. char[1] and we need not consider those > different. > > The fortran FE is similarly sloppy in other areas, see > > /* ??? We cannot simply use the type of operand #0 of the refs here > as the Fortran compiler smuggles type punning into COMPONENT_REFs > for common blocks instead of using unions like everyone else. */ > tree type1 = DECL_CONTEXT (field1); > tree type2 = DECL_CONTEXT (field2); I think the reason why tings work now is the following test: /* ??? In Ada, an lvalue of an unconstrained type can be used to access an object of one of its constrained subtypes, e.g. when a function with an unconstrained parameter passed by reference is called on an object and inlined. But, even in the case of a fixed size, type and subtypes are not equivalent enough as to share the same TYPE_CANONICAL, since this would mean that conversions between them are useless, whereas they are not (e.g. type and subtypes can have different modes). So, in the end, they are only guaranteed to have the same alias set. */ if (get_alias_set (type1) == get_alias_set (type2)) return -1; If you have arrays of compatible basetype, say int a[10] int b[var] or array and its basetype, say int a[10] int we will end up returning -1 because array alias set is basetype alias set unless it is TYPE_NONALIASED_COMPONENT (and I think those we should be able to skip inside the access patch oracles). With the array check removed we however will disambiguate int a[10]; short a[10]; This has similar effect as logic I implemented in the original patch (i.e. we can prove arrays to be incompatible, but without extra care about VLA bounds we can't prove them to be same) Honza > > > > > It does not seem to be that important, but looks odd > > and makes me woried about other changes :) > > > > Honza > > > > > > Richard. > > > > -- > Richard Biener > SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)