From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19418 invoked by alias); 30 Aug 2005 07:43:13 -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 19284 invoked by uid 48); 30 Aug 2005 07:43:08 -0000 Date: Tue, 30 Aug 2005 07:59:00 -0000 Message-ID: <20050830074308.19283.qmail@sourceware.org> From: "m dot reszat at kostal dot com" 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/msg03414.txt.bz2 List-Id: ------- Additional Comments From m dot reszat at kostal dot com 2005-08-30 07:43 ------- (In reply to comment #1) > (In reply to comment #0) > > > Access to bf1.b is correctly done as 32-bits (lwz/stw opcodes), bf2.b is > > accessed as 8-bits (lbz/stb opcodes). GCC3.4.3 shows the same behaviour, can't > > go back any further. The same happens when the bitfield itself is made volatile, > > not the whole struct. > > This is intentional. The idea is not to touch any more of that volatile stuff > than absolutely needed. Why do you think it is a bug? When dealing with peripherals in embedded systems, the use of bitfields makes the code much more readable. Ex.: 3 bits of a peripheral register define a timer prescaler It can be s.th. like #define PS_VAL_05 0x00140000 #define PS_MASK 0x001c0000 ... per_reg = (per_reg & ~PS_MASK) | PS_VAL_05; But could be as simple as per_reg.ps = 5;, or even per_reg.ps = func(...); Try to set up the latter w/o bitfields and you end up per_reg = (per_reg & ~PS_MASK) | (func(...) << PS_SHIFT); Most (admittedly not all) modern peripherals allow the bitfield approach, but correct access size is a must (misalignment traps, access triggered buffering etc.). IMHO the compiler/code generator should always use the basic type when a variable is declared as volatile, i.e. volatile unsigned int ps:3; should enforce 32-bit-access, probably even for non-bitfields. All compilers for embedded systems I know of act this way, so I assumed this was a bug. In other cases, e.g. communicating between threads through memory, access size is not an issue and even if so, could be enforced by appropriate declaration or, god help me, typecasting as a last resort. Unfortunately, C does not provide a qualifier for access size enforcement, "volatile" seems to be the closest friend. The current implementation puts me between a rock and a hard place, as the "core volatile functionality" is needed as well. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623