From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29491 invoked by alias); 10 Jan 2014 08:49:57 -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 29478 invoked by uid 89); 10 Jan 2014 08:49:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: dub0-omc3-s18.dub0.hotmail.com Received: from dub0-omc3-s18.dub0.hotmail.com (HELO dub0-omc3-s18.dub0.hotmail.com) (157.55.2.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Jan 2014 08:49:54 +0000 Received: from DUB122-W33 ([157.55.2.7]) by dub0-omc3-s18.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jan 2014 00:49:52 -0800 X-TMN: [KpnTUdZBhjpGQZTBuuuDMS14WVZsaimX] Message-ID: From: Bernd Edlinger To: Richard Earnshaw CC: Joey Ye , "gcc@gcc.gnu.org" , Sandra Loosemore Subject: RE: Still fails with strict-volatile-bitfields Date: Fri, 10 Jan 2014 08:56:00 -0000 In-Reply-To: <52CECCC9.1080007@arm.com> References: ,<52CECCC9.1080007@arm.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00073.txt.bz2 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 anyt= hing? >>> >>> 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. 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. 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=09=09=20=09=20=20=20=09=09=20=20