From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17413 invoked by alias); 30 Aug 2005 14:01:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17331 invoked by uid 48); 30 Aug 2005 14:01:02 -0000 Date: Tue, 30 Aug 2005 14:06:00 -0000 Message-ID: <20050830140102.17329.qmail@sourceware.org> From: "rearnsha at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050829140226.23623.m.reszat@kostal.com> References: <20050829140226.23623.m.reszat@kostal.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit X-Bugzilla-Reason: CC X-SW-Source: 2005-08/txt/msg03454.txt.bz2 List-Id: ------- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-30 14:00 ------- (In reply to comment #5) > I will try and dig up the EABI for PowerPC, but it's not just about sticking to > a paper. It simply does not work for me (and probably others) the way it is. Saying that because it doesn't work for you is not really addressing the issue. The point of specifications like this are so that they create a level playing field for all to start from (and thus avoid 'arguments' as to which one is correct). Ultimately, if your code doesn't work with the prescribed model, then you have to find another way of expressing the problem. Note, I'm not trying to judge here whether your expectations of the PPC ABI are right or wrong, I'm trying to set the rational for having ABI specifications and then trying to stick to them. > I can't quite see what can be gained by minimizing access size, but not knowing > the complete rationale (why are non-bitfields NOT minimized, e.g. volatile int x > |= 1), how about a command line switch to let the user select? I suspect it's historical. On a machine that can do arbitrary alignment (eg, traditional CISC processors) then a common layout rule for a bit-field is to place it as close as possible to the previous field such that it all fits in one 'access' (but probably multiple memory fetches -- afterall, the memory bus is still aligned). If that access happens to be volatile, then you still don't want the memory system to be accessed twice (even transparently) and you can normally guarantee that by 'narrowing' the object. For RISC processors the alignment tends to be more critical in the normal case, so bit-fields are generally laid out with more padding. In this situation it then makes more sense to say that the bit-field's type governs the nature of the memory access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623