From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10224 invoked by alias); 18 Apr 2003 00:14:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10211 invoked from network); 18 Apr 2003 00:14:56 -0000 Received: from unknown (HELO frothingslosh.sfbay.redhat.com) (12.150.115.200) by sources.redhat.com with SMTP; 18 Apr 2003 00:14:56 -0000 Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1]) by frothingslosh.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id h3I0DvNm012254; Thu, 17 Apr 2003 17:13:57 -0700 Received: (from rth@localhost) by frothingslosh.sfbay.redhat.com (8.12.8/8.12.8/Submit) id h3I0DvPk012252; Thu, 17 Apr 2003 17:13:57 -0700 X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Fri, 18 Apr 2003 01:16:00 -0000 From: Richard Henderson To: Richard Kenner Cc: aoliva@redhat.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT Message-ID: <20030418001357.GP6513@redhat.com> Mail-Followup-To: Richard Henderson , Richard Kenner , aoliva@redhat.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org References: <10304172034.AA10360@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10304172034.AA10360@vlsi1.ultra.nyu.edu> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-04/txt/msg00889.txt.bz2 On Thu, Apr 17, 2003 at 04:34:24PM -0400, Richard Kenner wrote: > But you don't mind if stand-alone objects of that type were > aligned stricter. You might. It depends on what you're doing with that object. Perhaps it's been put into a special section and so smooshed into an array created at link time. Indeed, that's *exactly* the case that caused us to respect USER_ALIGN in varasm.c at all costs. The fact of the matter is that this field is being overloaded for two meanings: (1) The user REALLY DID set the alignment, and expects it to be honored exactly as stated, and (2) The Ada front end is going about honoring Ada language semantics and doesn't want alignment increased in specific situations wrt types, but doesn't mind it being increased in other situations wrt objects. r~