From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33554 invoked by alias); 15 Oct 2015 23:24: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 33530 invoked by uid 89); 15 Oct 2015 23:24:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 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; Thu, 15 Oct 2015 23:24:19 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id AC1B3543006; Fri, 16 Oct 2015 01:24:15 +0200 (CEST) Date: Thu, 15 Oct 2015 23:24:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Richard Biener , gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Message-ID: <20151015232415.GC4230@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <3458949.DT0JXMSzxl@polaris> <1650238.MNS506uDsp@polaris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1650238.MNS506uDsp@polaris> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-10/txt/msg01529.txt.bz2 > > I'm not sure we need to care about TYPE_ALIGN_OK here so no objection by me. > > Actually I have one: can we please fix the multiple Ada breakages caused by > the previous controversial change from Jan before going farther in the series? > The build is still broken on IA-64 and I'm still seeing ICEs on x86. Or else > can we put the whole series on a branch until it is reasonably stable? I wasn't aware that x86/IA-64 is still broken. I am flying to NY tomorrow but will try to take a look. The ICEs are not caused by operand_equal_p changes, but the change to useless_type_conversion to ignore mode on aggregate types. A safe way would be to add the mode check back (as was in my original patch) that does not change my original intent to separate CANONICAL_TYPE from gimple semantic type equivalence machinery. It was however outcome of the discussion that we would preffer the mode to be ignored in this case which means fixing expansion side. I have no way to reproduce the IA-64 change, but will send proposed patch - from backtrace it was clear where the wrong mode went in. Will wait with operand_euqal_p changess until this is fixed. Honza > > -- > Eric Botcazou