From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113465 invoked by alias); 29 Oct 2015 03:39:40 -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 113389 invoked by uid 89); 29 Oct 2015 03:39:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,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; Thu, 29 Oct 2015 03:39:26 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 0DA27540853; Thu, 29 Oct 2015 04:39:22 +0100 (CET) Date: Thu, 29 Oct 2015 04:35:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, Richard Biener Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151029033922.GA52478@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <1456448.Tt4DpGVrAE@polaris> <20151021215701.GA14675@atrey.karlin.mff.cuni.cz> <2210014.Qgk3pAbeYD@polaris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2210014.Qgk3pAbeYD@polaris> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-10/txt/msg03126.txt.bz2 > > Added and comitted now. > > Thanks. Now on to the wrong code issues. :-) > > Up to the change, the useless_type_conversion_p predicate was relying on > structural equivalence via the TYPE_CANONICAL check, now it only looks at the > outermost level (size, mode). Now some back-ends, most notably x86-64, do a > deep structural scan to determine the calling conventions (classify_argument) > instead of just looking at the size and the mode, so consistency dictates that > the type of the argument and that of the parameter be structurally equivalent > and this sometimes can only be achieved by a VCE... which is now deleted. :-( > See the call to derivedIP in the attached testcase which now fails on x86-64. > > How do we get away from here? Hmm, I noticed this in ipa-icf context and wrote checker that two functions are ABI compatile (did not pushed it out yet), but of course this is nastier. I think the problem exists before my patch with LTO - it is just matter of doing two types which will be considered equivalent by gimple_canonical_types_compatible_p but have different type conversion. An example of such type would be: struct a { int a[4]; }; struct b { int a[4]; } __attribute__ ((__aligned__(16))); I tried to turn this into an testcase, the problem is that I don't know of a way to obtain VIEW_CONVERT_EXPR between the two types out of C or C++ frontend and we don't seem to synthetize these in middle end (even in cases it would make sense). I will try to play with it more - would be nice to have a C reproducer. We may be safe before my patch from wrong code issues if there is no way to rpduce VIEW_CONVERT_EXPR between types like this in languages that support aligned attribute. I think the problem is generally similar to memory references - the gimple type compatibility should not be tied to ABI details. Probably most consistent solution would be to extend GIMPLE_CALL to also list types of parameters and do not rely on whatever type the operand have.... Richard, any ideas? Honza > > > * gnat.dg/discr44.adb: New test. > > -- > Eric Botcazou > -- { dg-do run } > -- { dg-options "-gnatws" } > > procedure Discr44 is > > function Ident (I : Integer) return Integer is > begin > return I; > end; > > type Int is range 1 .. 10; > > type Str is array (Int range <>) of Character; > > type Parent (D1, D2 : Int; B : Boolean) is record > S : Str (D1 .. D2); > end record; > > type Derived (D : Int) is new Parent (D1 => D, D2 => D, B => False); > > X1 : Derived (D => Int (Ident (7))); > > begin > if X1.D /= 7 then > raise Program_Error; > end if; > end;