From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24314 invoked by alias); 9 May 2011 18:04:05 -0000 Received: (qmail 24305 invoked by uid 22791); 9 May 2011 18:04:04 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_CX,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 May 2011 18:03:47 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p49I3kZK002171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 May 2011 14:03:46 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p49I3kFe006841; Mon, 9 May 2011 14:03:46 -0400 Received: from [10.3.113.131] (ovpn-113-131.phx2.redhat.com [10.3.113.131]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p49I3i1N029106; Mon, 9 May 2011 14:03:45 -0400 Message-ID: <4DC82C80.5090308@redhat.com> Date: Mon, 09 May 2011 19:19:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Aldy Hernandez CC: Jason Merrill , gcc-patches Subject: Re: [C++0x] contiguous bitfields race implementation References: <4DC8155A.3040401@redhat.com> <4DC82136.6030802@redhat.com> <4DC823B4.9070204@redhat.com> In-Reply-To: <4DC823B4.9070204@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2011-05/txt/msg00681.txt.bz2 On 05/09/11 11:26, Aldy Hernandez wrote: > >>> struct >>> { >>> unsigned int a : 4; >>> unsigned char b; >>> unsigned int c: 6; >>> } var; > > >> Well, the kernel guys would like to be able to be able to preserve the >> padding bits too. It's a long long sad story that I won't repeat... >> And I don't think we should further complicate this stuff with the >> desire to not clobber padding bits :-) Though be aware the request >> might come one day.... > > Woah, let me see if I got this right. If we were to store in VAR.C > above, the default for this memory model would be NOT to clobber the > padding bits past ? That definitely makes my implementation simpler, > so I won't complain, but that's just weird. Just to be clear, it's something I've discussed with the kernel guys and is completely separate from the C++ memory model. I don't think we should wrap this into your current work. Consider if the kernel team wanted to add some information to a structure without growing the structure. Furthermore, assume that the structure escapes, say into modules that aren't necessarily going to be rebuilt, but those modules won't need to ever access this new information. And assume there happens to be enough padding bits to hold this auxiliary information. This has actually occurred and the kernel team wanted to use the padding bits to hold the auxiliary information and maintain kernel ABI/API compatibility. Unfortunately, a store to a nearby bitfield can overwrite the padding, thus if the structure escaped to a module that still thought the bits were padding, that module would/could clobber those padding bits, destroying the auxiliary data. If GCC had a mode where it would preserve the padding bits (when possible), it'd help the kernel team in these situations. > > Arghhh... I was afraid you'd ask for one. It was much easier with the > test harness on cxx-memory-model. I'll whip one up though... Given others have (rightly) called me out on it a lot recently, I figured I'd pass along the love :-) jeff