From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13251 invoked by alias); 10 Jan 2014 14:12: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 13240 invoked by uid 89); 10 Jan 2014 14:12: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; Fri, 10 Jan 2014 14:12:36 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Fri, 10 Jan 2014 14:12:34 +0000 Received: from [10.1.208.33] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jan 2014 14:12:31 +0000 Message-ID: <52CFFFCE.1050807@arm.com> Date: Fri, 10 Jan 2014 14:20: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: Richard Biener CC: Bernd Edlinger , Joey Ye , "gcc@gcc.gnu.org" , Sandra Loosemore Subject: Re: Still fails with strict-volatile-bitfields References: <52CECCC9.1080007@arm.com> <52CFC032.8070604@arm.com> In-Reply-To: X-MC-Unique: 114011014123401001 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00083.txt.bz2 On 10/01/14 13:45, Richard Biener wrote: > On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger > wrote: >> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote: >>> >>> On 10/01/14 08:49, Bernd Edlinger wrote: >>>> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote: >>>>> >>>>> On 09/01/14 08:26, Bernd Edlinger wrote: >>>>>> Hi, >>>>>> >>>>>> 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 = anything? >>>>>>> >>>>>>> Thanks, >>>>>>> Joey >>>>>> >>>>>> Yes, >>>>>> >>>>>> this is a major case where the C++ memory model is >>>>>> in conflict with AAPCS. >>>>>> >>>>> >>>>> 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. >>>> >>>> No. This example was working in 4.6 and broken in 4.7 and 4.8. >>>> Well, 4.7 should have warned about that. >>>> >>>> 4.9 does simply not change that, because it would violate the C++ >>>> memory model. Maybe that should go into release notes. >>> >>> That's no excuse for not generating a warning at compile time when the >>> situation is encountered. Users of this feature are experiencing a >>> quiet change of behaviour and that's unacceptable, even if the compiler >>> is doing what it was intended to do; that doesn't necessarily match the >>> user's expectations. There should always be a way to rewrite the C11 >>> intended semantics in a way that doesn't violate the strict volatile >>> bitfields semantics. >>> >> >> Hmm... >> You mean we should have a (ugly) warning enabled by default in 4.9 (at e= xpmed.c) >> if a bit-field access would be perfectly aligned and so, but is in confl= ict with the >> C++ memory model, and -fstrict-volatile-bitfields is in effect. >> Maybe only once per compilation? >=20 > I'd say you want a warning for the structure declaration instead > "Accesses to XYZ will not follow AACPS due to C++ memory model > constraints". >=20 Well AAPCS (note ordering of letters ;-) is target-specific. But 'strict volatile bitfields' would be fine. Watch out, though, for struct a { // bitfield decls ... }; volatile struct a *p; // Need the warning here R. > Richard. >=20 >> >>>> >>>> At the same time we had all kinds of invalid code generation, >>>> starting at 4.6, especially with packed structures in C and Ada(!), >>>> (writing not all bits, and using unaligned accesses) >>>> and that is fixed in 4.9. >>>> >>> >>> I'm not worried about packed structures. You can't sensibly implement >>> the strict volatile bitfields rules when things aren't aligned. >>> >>> R. >>> >>>> >>>> Bernd. >>>> >>>>> >>>>>> You can get the expected code, by changing the struct >>>>>> like this: >>>>>> >>>>>> struct str { >>>>>> volatile unsigned f1: 8; >>>>>> unsigned dummy:24; >>>>>> }; >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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! >>>>>> >>>>>> 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. >>>>>> >>>>>> But I did not yet try to implement this, as I feel that >>>>>> would certainly not be accepted as we are in Phase3 now. >>>>>> >>>>>> 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. >>>>>> >>>>>> Those people that do use bit-fields to access device-registers >>>>>> do always define all bits, and of course in the same mode. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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: >>>>>> >>>>>> 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. >>>>>> >>>>>> But that will come too late for Phase3 as well. >>>>>> >>>>>> >>>>>> Regards >>>>>> Bernd. >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >=20