From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29])
	by sourceware.org (Postfix) with ESMTPS id A70123858034
	for <gcc-patches@gcc.gnu.org>; Thu, 13 Oct 2022 08:14:53 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A70123858034
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
	by smtp-out2.suse.de (Postfix) with ESMTP id AB12E1F38A;
	Thu, 13 Oct 2022 08:14:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1665648892; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=mVmsqvcKeDXYA23oi/ghhGRch0wGncmj+6qjuqMD/eo=;
	b=Q/tGZkvWOOqx66BgQ+/GAwB8vAJLEeM1ovk6uy8bZ14JAsxug7Ac/DgbcM47N0lynVXSCU
	jmx877xm2zMbtkRKJi3Q+rXW1EFnq8yruxu52SAz94X54Zb8gMwB8jzJwSJ/k/JLn+gQM4
	cqseNeU79a2W8KNIzvfrU3gMOirW8Q0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1665648892;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=mVmsqvcKeDXYA23oi/ghhGRch0wGncmj+6qjuqMD/eo=;
	b=Fu11XZMsjvvljmCBoik3CTLpCZ/Pi80SnQriQwi2UuW9SZHclmP83DtVorwd6FttCO3+q8
	lRb5F/la4W/0Q3DQ==
Received: from wotan.suse.de (wotan.suse.de [10.160.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by relay2.suse.de (Postfix) with ESMTPS id A2A542C141;
	Thu, 13 Oct 2022 08:14:52 +0000 (UTC)
Date: Thu, 13 Oct 2022 08:14:52 +0000 (UTC)
From: Richard Biener <rguenther@suse.de>
To: "Andre Vieira (lists)" <andre.simoesdiasvieira@arm.com>
cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>, 
    Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]
In-Reply-To: <f84887dd-1d9e-e53f-b171-494426634026@arm.com>
Message-ID: <nycvar.YFH.7.77.849.2210130813270.18337@jbgna.fhfr.qr>
References: <f84887dd-1d9e-e53f-b171-494426634026@arm.com>
User-Agent: Alpine 2.22 (LSU 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>

On Wed, 12 Oct 2022, Andre Vieira (lists) wrote:

> Hi,
> 
> The bitposition calculation for the bitfield lowering in loop if conversion
> was not
> taking DECL_FIELD_OFFSET into account, which meant that it would result in
> wrong bitpositions for bitfields that did not end up having representations
> starting at the beginning of the struct.
> 
> Bootstrappend and regression tested on aarch64-none-linux-gnu and
> x86_64-pc-linux-gnu.

+    {
+      tree bf_pos = fold_build2 (MULT_EXPR, bitsizetype,
+                                DECL_FIELD_OFFSET (field_decl),
+                                build_int_cst (bitsizetype, 8));
+      bf_pos = fold_build2 (PLUS_EXPR, bitsizetype, bf_pos,
+                           DECL_FIELD_BIT_OFFSET (field_decl));
+      tree rep_pos = fold_build2 (MULT_EXPR, bitsizetype,
+                                 DECL_FIELD_OFFSET (rep_decl),
+                                 build_int_cst (bitsizetype, 8));
+      rep_pos = fold_build2 (PLUS_EXPR, bitsizetype, rep_pos,
+                            DECL_FIELD_BIT_OFFSET (rep_decl));

you can use the invariant that DECL_FIELD_OFFSET of rep_decl
and field_decl are always the same.  Also please use BITS_PER_UNIT
instead of '8'.

Richard.