From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4801 invoked by alias); 9 Jan 2014 16:22:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4791 invoked by uid 89); 9 Jan 2014 16:22:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Jan 2014 16:22:38 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Thu, 09 Jan 2014 16:22:35 +0000 Received: from [10.1.208.33] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jan 2014 16:22:34 +0000 Message-ID: <52CECCC9.1080007@arm.com> Date: Thu, 09 Jan 2014 16:30:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Bernd Edlinger CC: Joey Ye , "gcc@gcc.gnu.org" , "sandra@codesourcery.co" Subject: Re: Still fails with strict-volatile-bitfields References: In-Reply-To: X-MC-Unique: 114010916223513001 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00067.txt.bz2 On 09/01/14 08:26, Bernd Edlinger wrote: > Hi, >=20 > On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote: >> >> Sandra, Bernd, >> >> Can you take a look at >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59734 >> >> It seems a siimple case still doesn't work as expected. Did I miss anyth= ing? >> >> Thanks, >> Joey >=20 > Yes, >=20 > this is a major case where the C++ memory model is > in conflict with AAPCS. >=20 Does the compiler warn about this? And if so, is the warning on by default? I think it's essential that we don't have quiet changes in behaviour without such warnings. R. > You can get the expected code, by changing the struct > like this: >=20 > struct str { > volatile unsigned f1: 8; > unsigned dummy:24; > }; >=20 > If it is written this way the C++ memory model allows > QImode, HImode, SImode. And -fstrict-volatile-bitfields > demands SImode, so the conflict is resolved. This dummy > member makes only a difference on the C level, and is > completely invisible in the generated code. >=20 > If -fstrict-volatile-bitfields is now given, we use SImode, > if -fno-strict-volatile-bitfields is given, we give GCC the > freedom to choose the access mode, maybe QImode if that is > faster. >=20 > In the _very_ difficult process to find an solution > that seems to be acceptable to all maintainers, we came to > the solution, that we need to adhere to the C++ memory > model by default. And we may not change the default > setting of -fstruct-volatile-bitfields at the same time! >=20 > As a future extension we discussed the possibility > to add a new option -fstrict-volatile-bitfields=3Daapcs > that explicitly allows us to break the C++ memory model. >=20 > But I did not yet try to implement this, as I feel that > would certainly not be accepted as we are in Phase3 now. >=20 > As another future extension there was the discussion > about the -Wportable-volatility warning, which I see now > as a warning that analyzes the structure layout and > warns about any structures that are not "well-formed", > in the sense, that a bit-field fails to define all > bits of the container. >=20 > Those people that do use bit-fields to access device-registers > do always define all bits, and of course in the same mode. >=20 > It would be good to have a warning, when some bits are missing. > They currently have to use great care to check their structures > manually. >=20 > I had a proposal for that warning but that concentrated > only on the volatile attribute, but I will have to re-write > that completely so that it can be done in stor-layout.c: >=20 > It should warn independent of optimization levels or actual > bitfield member references, thus, be implemented entirely at > the time we lay out the structure. The well-formed-ness of > a bit-field makes that possible. >=20 > But that will come too late for Phase3 as well. >=20 >=20 > Regards > Bernd.=20=09=09=20=09=20=20=20=09=09=20=20 >=20 >=20