From patchwork Fri Mar 6 09:29:43 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 447052 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 56AB41400EA for ; Fri, 6 Mar 2015 20:29:57 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass reason="1024-bit key; unprotected key" header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=e8aaZEXD; dkim-adsp=none (unprotected policy); dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:from:to:cc:subject:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; q=dns; s= default; b=GQwvqw6io8M/VHNeDPTyk9E4wGxsyi1BQ7ahIV7tKYG2lyNyk3uC7 T7CTqrU14/5Ly/sfnYXvvddWINVH8dtxhq/1npxpiB1Jk+rEIyNZ4NtIdJQsFNVZ g6UWzMPfZtmEmM9ACfUrO8I+q92t2PqKAZyBwvrHzAMk2CYltnR9Ko= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:from:to:cc:subject:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s=default; bh=eXOxBXBr4apxenv6H2cqUsDrKiM=; b=e8aaZEXDrdx49S1ziRKWtREAHLcX QNoiFe3Xv9Syd6VpeIaTMU8QZ3w88lieU3DsnlBPwRDR48VxRpBIzWz3UdM6xIlB V30k8TBHF6axpckpS6XuTZ9Vcsqp5zN/MFRhUcVv/Q716/w5UazkmlW+BUlQY7fI 5C7q1aBta3XzL9s= Received: (qmail 30469 invoked by alias); 6 Mar 2015 09:29:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 30459 invoked by uid 89); 6 Mar 2015 09:29:48 -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: DUB004-OMC4S5.hotmail.com Received: from dub004-omc4s5.hotmail.com (HELO DUB004-OMC4S5.hotmail.com) (157.55.2.80) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Fri, 06 Mar 2015 09:29:47 +0000 Received: from DUB118-W37 ([157.55.2.73]) by DUB004-OMC4S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 6 Mar 2015 01:29:44 -0800 X-TMN: [xsajNU0gMFqnHTTiiAnK1o1Wqj5ujnuK] Message-ID: From: Bernd Edlinger To: Richard Biener CC: "gcc-patches@gcc.gnu.org" , Eric Botcazou Subject: RE: [PATCH] Fix another wrong-code bug with -fstrict-volatile-bitfields Date: Fri, 6 Mar 2015 10:29:43 +0100 In-Reply-To: References: , , , , , , MIME-Version: 1.0 Hi, On Thu, 5 Mar 2015 16:36:48, Richard Biener wrote: > > On Thu, Mar 5, 2015 at 4:05 PM, Bernd Edlinger > wrote: >> >> every access is split in 4 QImode accesses. but that is as >> expected, because the structure is byte aligned. > > No, it is not expected because the CPU can handle unaligned SImode > reads/writes just fine (even if not as an atomic operation). > The C++ memory model allows an SImode read to s.y (-fstrict-volatile-bitfields > would, as well, but the CPU doesn't guarantee atomic operation here) > Hmm, well.  I understand. However this is the normal way how the non-strict-volatile-bitfields work. But I can probably work out a patch that enables the strict-volatile-bitfields to generate un-aligned SImode accesses when necessary on !STRICT_ALIGNMENT targets. Now, I checked again the ARM port, and I am a bit surprised, because with gcc 4.9.0 this structure gets 4 QImode accesses which is correct, but with recent trunk (gcc version 5.0.0 20150301) I get SImode accesses, but the structure is not aligned and the compiler cant possibly know how the memory will be aligned.  Something must have changed in be meantime, but it wasn't by me. IIRC the field mode in this example was QImode but now it seems to be SImode. struct s {   unsigned int y:31; } __attribute__((packed)); int test (volatile struct s* x) {   x->y=0x7FFFFFFF;   return x->y; } So what would you think of this change at strict_volatile_bitfield_p? of course this is incomplete, and needs special handling for !STRICT_ALIGNMENT in the strict-volatile-bitfields code path later. Thanks Bernd. diff -up expmed.c.jj expmed.c --- expmed.c.jj    2015-01-16 11:20:40.000000000 +0100 +++ expmed.c    2015-03-06 10:07:14.362383274 +0100 @@ -472,9 +472,9 @@ strict_volatile_bitfield_p (rtx op0, uns      return false;      /* Check for cases of unaligned fields that must be split.  */ -  if (bitnum % BITS_PER_UNIT + bitsize> modesize -      || (STRICT_ALIGNMENT -      && bitnum % GET_MODE_ALIGNMENT (fieldmode) + bitsize> modesize)) +  if (bitnum % (STRICT_ALIGNMENT ? modesize : BITS_PER_UNIT) +      + bitsize> modesize +      || (STRICT_ALIGNMENT && MEM_ALIGN (op0) < modesize))      return false;      /* Check for cases where the C++ memory model applies.  */