From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24514 invoked by alias); 20 Mar 2003 23:44:59 -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 24505 invoked from network); 20 Mar 2003 23:44:58 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 20 Mar 2003 23:44:58 -0000 Received: from prospero.boston.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h2KNivo28238; Thu, 20 Mar 2003 18:44:57 -0500 Received: by prospero.boston.redhat.com (Postfix, from userid 4046) id 324C9F81E5; Thu, 20 Mar 2003 23:41:19 +0000 (GMT) To: gcc@gcc.gnu.org Cc: Andrew Haley , Jakub Jelinek , Jason Merrill Subject: On alignment From: Jason Merrill Date: Fri, 21 Mar 2003 00:25:00 -0000 Message-ID: User-Agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg01321.txt.bz2 Andrew Haley recently pointed me at an alignment bug: http://gcc.gnu.org/ml/gcc/2003-03/msg01196.html Here, the presence of an aligned attribute is giving the field alignment of 8, even though only 4 was requested. This worked in 2.95, but has been broken in all 3.x releases (i.e. since Jakub's *_USER_ALIGN changes). This happens because DECL_USER_ALIGN overrides BIGGEST_FIELD_ALIGNMENT. The right way to handle this is to clear DECL_USER_ALIGN when rounding up DECL_ALIGN to TYPE_ALIGN; the code in layout_decl gets this right, but check_field_decl in the C++ frontend and finish_struct in the C frontend get it wrong. Do people think this bug is worth fixing? The behavior is rather surprising, but changing it might break binary compatibility for affected code--of which there's not likely to be very much, but there could be some. Code which really wants, say, aligment of 4 for long long could say __attribute__ ((packed, aligned (4))). On the other hand, the change would restore binary compatibility with 2.95 for C code. Jason Asides: it seems to me that there's no reason for the frontends to be messing with this sort of thing without a good reason; record layout should be handled in stor-layout.c as much as possible. Most of the existing code in the C and C++ frontends that touch DECL_ALIGN is redundant. Also, I noticed that EMPTY_FIELD_BOUNDARY is only handled in the frontend, and that it is ignored on targets which define PCC_BITFIELD_TYPE_MATTERS, though that is not made clear in tm.texi. I plan to clean these bits up while I'm looking at this stuff.