From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10610 invoked by alias); 8 Sep 2005 15:12:56 -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 10585 invoked by uid 48); 8 Sep 2005 15:12:52 -0000 Date: Thu, 08 Sep 2005 15:12:00 -0000 Message-ID: <20050908151252.10584.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-09/txt/msg00951.txt.bz2 List-Id: ------- Additional Comments From m dot reszat at kostal dot com 2005-09-08 15:12 ------- (In reply to comment #6) > (In reply to comment #5) > > I will try and dig up the EABI for PowerPC > > > Note this also happens on ARM where (in the EABI) it is definitely a bug None of the documents I found makes a statement as clear as the ARM EABI does. Can someone point me to the source file where the "narrowing" is done, to maybe simply "comment it out"?; I don't feel capable of providing a real fix, see below, but I also don't want to rewrite large portions of my code when migrating to GCC. Having given more thought to the problem, isn't the "narrowing" an optimization which should not be a fixed property of the compiler, given that even for the same type of machine ("target") there can exist various different memory interfaces? Hence, shouldn't it be an optimization option, "on" by default to be backwards compatible? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623