From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15941 invoked by alias); 22 Jun 2015 16:16:11 -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 15929 invoked by uid 89); 22 Jun 2015 16:16:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham 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; Mon, 22 Jun 2015 16:16:09 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 9A32D540930; Mon, 22 Jun 2015 18:16:05 +0200 (CEST) Date: Mon, 22 Jun 2015 16:17:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , Joseph Myers , gcc-patches@gcc.gnu.org, burnus@net-b.de Subject: Re: Fix more of C/fortran canonical type issues Message-ID: <20150622161605.GE15633@kam.mff.cuni.cz> References: <20150608144415.GA23542@kam.mff.cuni.cz> <20150608150837.GC23542@kam.mff.cuni.cz> <20150609170716.GB96004@kam.mff.cuni.cz> <20150622070720.GA71122@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-06/txt/msg01460.txt.bz2 > > Hi, > > I would like to ping this. There are still few things to fix to make our > > merging compliant at least for C/C++/Fortran rules (the array bounds for > > Fortran and union ordering for C I believe) and I would like to progress > > on this. > > I don't like the changes to useless_type_conversion_p much. Why > do you preserve qualifiers for the integer kind compares? > > All the testcases have the integral types in aggregates as members. > I already said that I'm happy globbing them together in aggregates. I originally made the testcase this way because I wanted to test the way aggregates are built and because it needs less of fortran code to realize it. It is possible to consutrct same testcase with scalar variables. See the other patch fixing the surprious warning. You need also variant "size_t a" to be compatible with fortran equivalent of "signed size_t a", so it is not only about variables. > > I'm still not convinced that we need a 1:1 correspondence between > canonical types and alias sets. In particular canonical types are > used for type compatibility in lhs = rhs assignments > (useless_type_conversion_p) which is a transitive relation. > Mixing both too much will cause serious confusion. We have > alias-sets for a reason. OK, I am not sure if canonical types needs to actually mean the type compatibility in the middle-end sense. It is a language specific thing: The "canonical" type for this type node, which is used by frontends to compare the type for equality with another type. If two types are equal (based on the semantics of the language), then they will have equivalent TYPE_CANONICAL entries. In a way TYPE_CANONICAL seems bit schizofrenic about if it means language level compatibility, representation compatibility or middle end semantic compatibility. It seems bit odd to define something like useless_type_conversion_p by language specific manner despite the fact its definition is now sound in language independent way as we now have all semantics represented in IL (and flags, well) but I would be happy to update the patch to assign different canonical types to signed/unsigned integers and avoid recursion on those for aggregates/arrays and all other derived types. (After all I plan to do that for pointers incrementally) Here we are "lucky" that alias.c already contains the globbing for signed/unsigned. Do we want to do the same scheme in other cases? For example next on my list is the fact that array with bounds 3...5 is interoperable with array[3] in C. Here again we can not consider these useless_type_conversion_p because index operation is different, but they are representation compatible. This will need a special case in get_alias_set. I would not like to make get_alias_set, or (with less loss of code quality on non-C languages) in lto's get_alias_set langhook. Honza > > Richard.