From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84769 invoked by alias); 4 Nov 2015 16:50:15 -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 84760 invoked by uid 89); 4 Nov 2015 16:50:14 -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,T_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; Wed, 04 Nov 2015 16:50:13 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id AA9AC54314B; Wed, 4 Nov 2015 17:50:09 +0100 (CET) Date: Wed, 04 Nov 2015 16:50:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, Andreas Schwab , Richard Biener Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151104165009.GB63428@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <1502746.PVjyRxddou@polaris> <20151104072302.GA15669@kam.mff.cuni.cz> <4208196.7D90TBgezR@polaris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4208196.7D90TBgezR@polaris> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-11/txt/msg00372.txt.bz2 > > Are these supposed to be fixed by Richard's change to not use > > useless_type_conversion for VCE, or is it another issue? > > Richard's change not to use useless_type_conversion for VCE was causing > additional GIMPLE verification failures so I didn't pursue; I can try again, > but all the known regressions are now fixed thanks to Richard's latest change > to useless_type_conversion_p itself. I see, you re-instantiated the TYPE_CANONICAL check for aggregates instead. I guess it is most practical way to go right now even though it would be really nice to separate this from TBAA machinery. At the moment LTO doesn't do globbing where calling conventions should care. One such case is the globing of array containing char and char which is required by Fortran standard, but that IMO is a defect in standard - if types are passed differently by target ABI one can't expect them to be fuly interoperable as Fortran would like. Thank you very much for looking into this! Honza > > -- > Eric Botcazou