From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25014 invoked by alias); 10 Jan 2014 13:45:20 -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 25004 invoked by uid 89); 10 Jan 2014 13:45:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f179.google.com Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 10 Jan 2014 13:45:15 +0000 Received: by mail-wi0-f179.google.com with SMTP id z2so4840145wiv.12 for ; Fri, 10 Jan 2014 05:45:12 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.108.132 with SMTP id hk4mr2868782wib.12.1389361512785; Fri, 10 Jan 2014 05:45:12 -0800 (PST) Received: by 10.194.243.105 with HTTP; Fri, 10 Jan 2014 05:45:12 -0800 (PST) In-Reply-To: References: <52CECCC9.1080007@arm.com> <52CFC032.8070604@arm.com> Date: Fri, 10 Jan 2014 14:12:00 -0000 Message-ID: Subject: Re: Still fails with strict-volatile-bitfields From: Richard Biener To: Bernd Edlinger Cc: Richard Earnshaw , Joey Ye , "gcc@gcc.gnu.org" , Sandra Loosemore Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00082.txt.bz2 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=59734 >>>>>> >>>>>> 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 expmed.c) > if a bit-field access would be perfectly aligned and so, but is in conflict with the > C++ memory model, and -fstrict-volatile-bitfields is in effect. > Maybe only once per compilation? 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". Richard. > >>> >>> 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=aapcs >>>>> 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. >>>>> >>>>> >>>> >>>> >>> >> >>