From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10475 invoked by alias); 11 Jun 2010 16:15:51 -0000 Received: (qmail 10406 invoked by uid 22791); 11 Jun 2010 16:15:42 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Jun 2010 16:15:36 +0000 Received: (qmail 7660 invoked from network); 11 Jun 2010 16:15:35 -0000 Received: from unknown (HELO ?192.168.0.104?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Jun 2010 16:15:35 -0000 Message-ID: <4C126123.2060004@codesourcery.com> Date: Fri, 11 Jun 2010 16:42:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: DJ Delorie CC: "Joseph S. Myers" , gcc-patches@gcc.gnu.org Subject: Re: patch: honor volatile bitfield types References: <201006110338.o5B3cuA3031982@greed.delorie.com> <201006111352.o5BDqnnh013901@greed.delorie.com> In-Reply-To: <201006111352.o5BDqnnh013901@greed.delorie.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg01229.txt.bz2 DJ Delorie wrote: >> Shouldn't the default actually be target-specific (no new hooks needed, >> existing hooks to set options in a target-specific way should suffice, >> though maybe you need to initialize the flag setting to -1 to allow >> OVERRIDE_OPTIONS to know whether it was explicitly set)? For example, ARM >> EABI should enable this by default. > > Yes, it should. I figured, let's get the functionality working first, > then let the target maintainers decide which targets need it on and > which off. Very glad to see this functionality. However, before it goes in, I think the change that Joseph is suggesting (which is perhaps just a documentation change to say that the default is target-dependent) shold occur. Here's some proposed words for the documentation: == Access volatile structure fields (including bitfields) by using a single read or write, and by loading as few bits as possible to load the field. For example, when loading a @type{char} bitfield on a machine with an 8-bit @type{char}, use either an 8-bit load instruction (if the entire bitfield fits within a single byte) or a 16-bit load instruction (if the bitfield spans two bytes). If honoring these constraints would result in an unaligned access on a machine where unaligned accesses are not permitted, the compiler issues a warning and does not generate an unaligned access. If this option is disabled, the compiler will use the most efficient instruction. In the previous example, that might be a 32-bit load instruction, even though that will access bytes that do not contain any portion of the bitfield. The default value of this option is determined by the application binary interface for the target processor. == I think that's a more user-centric description of the option. If I've gotten the details wrong, please correct them. If you need someone to review this patch after it's been revised, please let me know. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713