From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45062 invoked by alias); 29 May 2019 12:53:52 -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 44590 invoked by uid 89); 29 May 2019 12:53:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_PASS autolearn=ham version=3.3.1 spammy=areas X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 May 2019 12:53:51 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CB596AC8A; Wed, 29 May 2019 12:53:48 +0000 (UTC) Date: Wed, 29 May 2019 12:56:00 -0000 From: Richard Biener To: Jan Hubicka cc: gcc-patches@gcc.gnu.org, d@dcepelik.cz Subject: Re: Teach same_types_for_tbaa to structurally compare arrays, pointers and vectors In-Reply-To: <20190529123353.kfsfisrm5mkzm6rv@kam.mff.cuni.cz> Message-ID: 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> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609908220-539078742-1559134428=:10704" X-SW-Source: 2019-05/txt/msg01895.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-539078742-1559134428=:10704 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-length: 2134 On Wed, 29 May 2019, Jan Hubicka wrote: > > On Mon, 27 May 2019, Jan Hubicka wrote: > > > > > Hi, > > > this is minimal version of patch adding just the pointer compare. > > > Bootstrapped/regtested x86_64-linux, makes sense? :) > > > > Yes, obviously. > > Thanks, i will go ahead with installing it. > Note that I have also tested removal of: > > /* ??? 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); > 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) ---1609908220-539078742-1559134428=:10704--