From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125284 invoked by alias); 19 Oct 2015 07:46:30 -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 125220 invoked by uid 89); 19 Oct 2015 07:46:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 19 Oct 2015 07:46:29 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 0FEA227BB142; Mon, 19 Oct 2015 09:46:26 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzHNrhLPHKzw; Mon, 19 Oct 2015 09:46:25 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id C9F5027BB0E1; Mon, 19 Oct 2015 09:46:25 +0200 (CEST) From: Eric Botcazou To: Jan Hubicka Cc: gcc-patches@gcc.gnu.org, Richard Biener Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p Date: Mon, 19 Oct 2015 07:58:00 -0000 Message-ID: <21255721.Or0yReY6Nx@polaris> User-Agent: KMail/4.14.9 (Linux/3.16.7-24-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20151018160651.GA63497@kam.mff.cuni.cz> References: <20151014162944.GE16672@kam.mff.cuni.cz> <1833908.my5suBVC6X@polaris> <20151018160651.GA63497@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2015-10/txt/msg01702.txt.bz2 > Why is Ada fliddling with the modes? Is it only for packed structures? Yes, in Ada packing or representation clauses are allowed to modify the type of components, so you can have e.g. a record type with size S1 and BLKmode and fields of this type with a packed version of this record type (with size S2 I was wondering how to produce VCE convesions of aggregates with C frontend > at all (that is getting them synthetized by the middle-end) to get non-ada > testcases. Storing through union is never folded to one and I don't see > any other obvious way of getting them. Perhaps it may be possible to get > them via inliner on incompatible parameter and LTO, but that seems to be > the only case I can think of right now. That makes sense, all the machinery implementing type fiddling for the Ada compiler is in gigi, not in stor-layout.c for example. > I am testing the change to compare modes and revert the two expr.c changes. > Lets see what is Richard's opinion. The whole concept of modes on aggregate > types is bit funny post-tree-ssa days when we do SRA. I suppose they may be > tied to calling conventions but should no longer be needed for code quality? Ideally it should not be tied to calling conventions either, but it is known that some back-ends still use it for this purpose. -- Eric Botcazou