From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18153 invoked by alias); 22 Jun 2004 20:49:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 18145 invoked from network); 22 Jun 2004 20:49:10 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org with SMTP; 22 Jun 2004 20:49:10 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i5MKkCp4022283; Tue, 22 Jun 2004 16:46:12 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5MKn9w26973; Tue, 22 Jun 2004 16:49:09 -0400 Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i5MKn8P13374; Tue, 22 Jun 2004 13:49:08 -0700 Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1]) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i5MKn8Qw012627; Tue, 22 Jun 2004 13:49:08 -0700 Received: (from rth@localhost) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i5MKn874012625; Tue, 22 Jun 2004 13:49:08 -0700 X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Tue, 22 Jun 2004 21:37:00 -0000 From: Richard Henderson To: Richard Kenner Cc: gcc-patches@gcc.gnu.org Subject: Re: Patch to allow Ada to work with tree-ssa Message-ID: <20040622204908.GB12399@redhat.com> Mail-Followup-To: Richard Henderson , Richard Kenner , gcc-patches@gcc.gnu.org References: <10406221952.AA09590@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10406221952.AA09590@vlsi1.ultra.nyu.edu> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-06/txt/msg01800.txt.bz2 On Tue, Jun 22, 2004 at 03:52:25PM -0400, Richard Kenner wrote: > Using TYPE_ALIGN doesn't work because you don't know whether all the fields > in the path are aligned that way. They might be "bit fields" that are > misaligned. Before highest_pow2_factor and the MEM_ALIGN addition, we used > to get this wrong a lot. Now we are very precise. Surely you're applying highest_pow2_factor step-by-step as you walk down the components. Which means that the TYPE_ALIGN is just fine. I'm absolutely certain that this *must* change. For exactly the same reason that we added TYPE_SIZE_UNIT, we do not want to be doing pointer arithmetic in units other than bytes. > Sure, but by that argument we can allow > in > GIMPLE! My point is that REALPART_EXPR and IMAGPART_EXPR have inputs and > outputs that are both scalars, so it would seem more in keeping with > the GIMPLE strategy to not mix them with other operations. This is wrong. REALPART_EXPR is not like other gimple operands because (irritatingly) it is an lvalue. You can take its address. It has *exactly* the same semantics as or . So it should be treated the same way. r~