From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13906 invoked by alias); 22 Mar 2012 11:48:12 -0000 Received: (qmail 13898 invoked by uid 22791); 22 Mar 2012 11:48:11 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Mar 2012 11:47:59 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 024B9290010; Thu, 22 Mar 2012 12:48:01 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWxB-5+MNhL7; Thu, 22 Mar 2012 12:48:00 +0100 (CET) Received: from [192.168.1.2] (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id BBD52290052; Thu, 22 Mar 2012 12:48:00 +0100 (CET) From: Eric Botcazou To: Richard Guenther Subject: Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere Date: Thu, 22 Mar 2012 11:48:00 -0000 User-Agent: KMail/1.9.9 Cc: gcc-patches@gcc.gnu.org References: <201203221213.16087.ebotcazou@adacore.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201203221247.42692.ebotcazou@adacore.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 2012-03/txt/msg01495.txt.bz2 > But the bitfield group _does_ start on a byte boundary. At least > that's what the new code in stor-layout ensures. No, it doesn't, since it does the computation on a record by record basis. Here we have a bitfield group that starts in a record and ends up in a nested record. > It's ok to assume the group starts on a byte boundary. But it's not > ok to modify bits outside of the access, so the RMW cycle has to mask > them properly. We have 2 options: 1. the GCC 4.7 approach where get_bit_range returns 0 for bitstart, which doesn't make much sense but is in keeping with store_bit_field. 2. the GCC 4.8 approach where get_bit_range attempts to return a more correct value, but is currently wrong (bitregion_start=11, bitregion_end=18) because the representative of the bitfield is wrong. The real representative of the bitfield is outside the record type. -- Eric Botcazou