From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14535 invoked by alias); 23 Jan 2012 22:08:37 -0000 Received: (qmail 14518 invoked by uid 22791); 23 Jan 2012 22:08:35 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jan 2012 22:08:22 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1RpS3p-00051a-2G from Bernd_Schmidt@mentor.com ; Mon, 23 Jan 2012 14:08:21 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 14:08:20 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Mon, 23 Jan 2012 22:08:18 +0000 Message-ID: <4F1DDA50.3060101@codesourcery.com> Date: Mon, 23 Jan 2012 22:08:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110920 Lightning/1.0b3pre Thunderbird/3.1.12 MIME-Version: 1.0 To: DJ Delorie CC: Subject: Re: Continue strict-volatile-bitfields fixes References: <000801cca086$dcd59b30$9680d190$@ye@arm.com> <4EBD4BCB.4080807@codesourcery.com> <4ED50901.8090300@codesourcery.com> <4F1D72CA.1060908@codesourcery.com> <201201231951.q0NJp1fG011544@greed.delorie.com> In-Reply-To: <201201231951.q0NJp1fG011544@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: 2012-01/txt/msg01179.txt.bz2 On 01/23/2012 08:51 PM, DJ Delorie wrote: > >> and I think applying strict-volatile-bitfields to enums is probably >> meaningless. > > MCU vendors would disagree. If a location is volatile, it's most > likely hardware, and must be accessed in the user-specified way. > Randomly accessing adjacent locations could cause system failure. This is not an issue here. The optimization in question in stor-layout tries to find out if a bitfield (volatile or not) is laid out in a way that's equivalent to a natural machine mode. For example, a 2-byte aligned 16 bit value can be HImode on most targets. The earlier patch restricts this optimization for non-volatile bitfields as well, on the grounds that an object may later be declared as volatile even if the bitfield isn't declared volatile in the struct definition. Strict-volatile-bitfields is concerned with the opposite case: ensuring that an "int x:8;" is accessed only with int-sized accesses. My thought was that this is probably pointless with enums, which I think aren't usually thought of as a specific size unlike char/short/int. So, if we see "enum something x:8;" we don't want to prevent the compiler from treating this as a plain QImode non-bitfield member. Bernd