From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72307 invoked by alias); 29 Oct 2015 15:02:21 -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 72265 invoked by uid 89); 29 Oct 2015 15:02:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,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 15:02:19 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 603885441DA; Thu, 29 Oct 2015 16:02:15 +0100 (CET) Date: Thu, 29 Oct 2015 15:06:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , Eric Botcazou , GCC Patches Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151029150215.GA34652@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <1456448.Tt4DpGVrAE@polaris> <20151021215701.GA14675@atrey.karlin.mff.cuni.cz> <2210014.Qgk3pAbeYD@polaris> <20151029033922.GA52478@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-10/txt/msg03193.txt.bz2 > > IMHO it was always wrong/fragile for backends to look at the actual arguments to > decide on the calling convention. The backends should _solely_ rely on > gimple_call_fntype and its TYPE_ARG_TYPES here. > > Of course then there are varargs ... (not sure if we hit this here). Yep, you have varargs and K&R prototypes, so it can't work this way. > > But yes, the VIEW_CONVERT "stripping" is a bit fragile and I don't remember > what exactly we gain from it (when not done on registers). I guess gain is really limited to Ada - there are very few cases we do VCE otherwise. (I think we could do more of them). We can make useless_type_conversion NOP/CONVERT only. That in fact makes quite a sense because those are types with gimple operations on it. Perhaps also VCE on vectors, but not VCE in general. Honza > > But I also don't see where we do the stripping mentioned on memory references. > The match.pd pattern doesn't apply to memory, only in the GENERIC path > which is guarded with exact type equality. So I can't see where we end up > stripping the V_C_E. > > There is one bogus case still in fold-const.c: > > case VIEW_CONVERT_EXPR: > if (TREE_CODE (op0) == MEM_REF) > /* ??? Bogus for aligned types. */ > return fold_build2_loc (loc, MEM_REF, type, > TREE_OPERAND (op0, 0), TREE_OPERAND (op0, 1)); > > return NULL_TREE; > > that comment is only in my local tree ... (we lose alignment info that is > on the original MEM_REF type which may be a smaller one). > > Richard. > > > 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; > >